LLDB porting docs

Hi,

I am looking forward to use LLDB to port to a VLIW architecture, can anyone help me by providing some pointers to documents or Readme texts… ?

thanks and regards,
tyagi






|

|

There currently aren't any documents. I need to sit down and write them sometime soon.

A few questions:

The big one: Does LLVM support the VLIW architecture? If not we won't have a way to evaluate expressions, or disassemble. This would be a show stopper if there is no LLVM support.

What file format will the executables for VLIW be using? Hopefully ELF32 of ELF64? If so, then there is no work to be done on the ObjectFile parser side.

Is this for bareboard or OS development?
  If bareboard, no work needs to be done on the DynamicLoader plug-in side.
  If OS developtment where you will have shared libraries loading/unloading then you will need to write a DynamicLoader plug-in for your OS or kernel.

The plug-ins you will then need to subclass and create would be:
- lldb_private::Platform
- lldb_private::ABI
- lldb_private::Process

The Platform plug-in helps answer questions like "where is the file /usr/lib/libfoo.so locally on this machine" when you are doing a debug session. It also helps with locating executables in bundles, and selecting the right architecture from executables if you have an executable bundle or binary that contains one or more architecture versions.

The ABI plug-in helps us to be able to find out where arguments are passed when making function calls and when looking for return values from function calls. It also helps define a whole bunch of other things that are defined by the ABI like which registers are spilled/volatile/etc.

The Process plug-in is the part that connects to your remote system. If you are using a JTAG library that can speak the GDB remote protocol, you might not have to write a Process plug-in. how do you communicate and debug your executables? Do you have a running OS where lldb is running in user space on that OS? Will you be doing remote debugging? If so, how does one communicate with your remote debug session?

Greg Clayton

Does LLVM support the VLIW architecture?

Yes, the LLVM supports VIW architecture, the compiler tool chain for which i
am planning to port LLDB is based on LLVM.

What file format will the executables for VLIW be using? Hopefully ELF32 of

ELF64?

Our executable file format is ELF32.

The Process plug-in is the part that connects to your remote system. If you
are using a JTAG library that can speak the GDB remote protocol, you might
not have to write a Process plug-in. how do you communicate and debug your
executables? Do you have a running OS where lldb is running in user space on
that OS? Will you be doing remote debugging?

We plan for remote debugging, we plan to modify the existing target simulator
to communicate with ported LLDB. In that case, LLDB may work as a client
asking for information from a Target simulator, which is considered as a
server.

I hope i answered your doubts. If you have further question please let me
know, i will explore and try to answer.

Moreover, i observed that LLDB supports remote debugging, however, i do not
know the details. If possible please share some information about remote
debugging supported in LLDB.

Regards,
Mool Chand Tyagi

Greg Clayton <gclayton <at> apple.com> writes:

There currently aren't any documents. I need to sit down and write them

sometime soon.

A few questions:

The big one: Does LLVM support the VLIW architecture? If not we won't have a

way to evaluate expressions, or

disassemble. This would be a show stopper if there is no LLVM support.

What file format will the executables for VLIW be using? Hopefully ELF32 of

ELF64? If so, then there is no

work to be done on the ObjectFile parser side.

Is this for bareboard or OS development?
  If bareboard, no work needs to be done on the DynamicLoader plug-in side.
  If OS developtment where you will have shared libraries loading/unloading

then you will need to write a

DynamicLoader plug-in for your OS or kernel.

The plug-ins you will then need to subclass and create would be:
- lldb_private::Platform
- lldb_private::ABI
- lldb_private::Process

The Platform plug-in helps answer questions like "where is the

file /usr/lib/libfoo.so locally on this

machine" when you are doing a debug session. It also helps with locating

executables in bundles, and

selecting the right architecture from executables if you have an executable

bundle or binary that

contains one or more architecture versions.

The ABI plug-in helps us to be able to find out where arguments are passed

when making function calls and when

looking for return values from function calls. It also helps define a whole

bunch of other things that are

defined by the ABI like which registers are spilled/volatile/etc.

The Process plug-in is the part that connects to your remote system. If you

are using a JTAG library that can

speak the GDB remote protocol, you might not have to write a Process plug-

in. how do you communicate and

debug your executables? Do you have a running OS where lldb is running in

user space on that OS? Will you be

doing remote debugging? If so, how does one communicate with your remote

debug session?

Greg Clayton

> Hi,
>
> I am looking forward to use LLDB to port to a VLIW architecture, can

anyone help me by providing some

Does LLVM support the VLIW architecture?

Yes, the LLVM supports VIW architecture, the compiler tool chain for which i
am planning to port LLDB is based on LLVM.

That is good.

What file format will the executables for VLIW be using? Hopefully ELF32 of

ELF64?

Our executable file format is ELF32.

Great!

The Process plug-in is the part that connects to your remote system. If you
are using a JTAG library that can speak the GDB remote protocol, you might
not have to write a Process plug-in. how do you communicate and debug your
executables? Do you have a running OS where lldb is running in user space on
that OS? Will you be doing remote debugging?

We plan for remote debugging, we plan to modify the existing target simulator
to communicate with ported LLDB. In that case, LLDB may work as a client
asking for information from a Target simulator, which is considered as a
server.

I hope i answered your doubts. If you have further question please let me
know, i will explore and try to answer.

Moreover, i observed that LLDB supports remote debugging, however, i do not
know the details. If possible please share some information about remote
debugging supported in LLDB.

We use the GDB remote protocol for debugging with extensions to allow for discoverability. We also have some packets that implement a remote "platform" which would allow you to list remote processes, attach or launch processes and more built into the GDB remote protocol. The platform stuff is still a work in progress, but we eventually plan to flesh everything out and perfect it.

The GDB remote protocol is documented on the web, and the LLDB specific extensions are documented in:

svn cat http://llvm.org/svn/llvm-project/lldb/trunk/docs/lldb-gdb-remote.txt

Let me know if you have any other questions.