NativeProcessProtocol and GetSharedLibraryInfoAddress()

Subprojects LLDB
1

Hey Greg,

At the moment I’m working on implementing the NativeProcessProtocol::GetSharedLibraryInfoAddress () method for Linux.

From the docs:

//----------------------------------------------------------------------
// “qShlibInfoAddr”
//
// BRIEF
// Get an address where the dynamic linker stores information about
// where shared libraries are loaded.
//
// PRIORITY TO IMPLEMENT
// High if you have a dynamic loader plug-in in LLDB for your target
// triple (see the “qHostInfo” packet) that can use this information.
// Many times address load randomization can make it hard to detect
// where the dynamic loader binary and data structures are located and
// some platforms know, or can find out where this information is.
//
// Low if you have a debug target where all object and symbol files
// contain static load addresses.
//----------------------------------------------------------------------
LLDB and GDB both support the “qShlibInfoAddr” packet which is a hint to each
debugger as to where to find the dynamic loader information. For darwin
binaires that run in user land this is the address of the “all_image_infos”
stucture in the “/usr/lib/dyld” executable, or the result of a TASK_DYLD_INFO
call. The result is returned as big endian hex bytes that are the address
value:
send packet: $qShlibInfoAddr#00

read packet: $7fff5fc40040#00

I presume I will have the gdb remote qShlibInfoAddr handler in GDBRemoteCommunicationServer handle this by deferring to NativeProcessProtocol::GetSharedLibraryInfoAddress (),

A few questions on this:

Q: This needs to be a loaded address value, correct? Given the comments in the priority section, it seems so, and much of the shared library info on elf (rendezvous structures and such) is only available in memory form. Just wanting to check my assumption because if it is wrong, the other question is moot.

Q: Is it fair for NativeProcessProtocol to make use of the Target class? An overall goal is to limit how much NativeProcesProtocol needs to touch, which will help limit how much of lldb proper needs to be linked in on the lldb-gdbserver side. In this case, I’m finding that load address calculation (e.g. via ObjectFileELF::GetImageInfoAddress (Target *) ) ultimately need a Target to resolve a load address. I’m thinking the answer would be no. I think we would want to avoid using Target within llgs (lldb-gdbserver). If that’s the case, I’ll need to duplicate some of the Section/SectionLoadList handling. When looking at the Target set of functionality, it has a bunch of concepts that I’m thinking we don’t want to have to link in just to have the load address resolution (e.g. broadcasters, execution contexts, heavy breakpoints, etc.)

Thoughts here?

Thanks!

2

Hey Greg,

At the moment I'm working on implementing the NativeProcessProtocol::GetSharedLibraryInfoAddress () method for Linux.

From the docs:

//----------------------------------------------------------------------
// "qShlibInfoAddr"
//
// BRIEF
// Get an address where the dynamic linker stores information about
// where shared libraries are loaded.
//
// PRIORITY TO IMPLEMENT
// High if you have a dynamic loader plug-in in LLDB for your target
// triple (see the "qHostInfo" packet) that can use this information.
// Many times address load randomization can make it hard to detect
// where the dynamic loader binary and data structures are located and
// some platforms know, or can find out where this information is.
//
// Low if you have a debug target where all object and symbol files
// contain static load addresses.
//----------------------------------------------------------------------

LLDB and GDB both support the "qShlibInfoAddr" packet which is a hint to each
debugger as to where to find the dynamic loader information. For darwin
binaires that run in user land this is the address of the "all_image_infos"
stucture in the "/usr/lib/dyld" executable, or the result of a TASK_DYLD_INFO
call. The result is returned as big endian hex bytes that are the address
value:

send packet: $qShlibInfoAddr#00
read packet: $7fff5fc40040#00

I presume I will have the gdb remote qShlibInfoAddr handler in GDBRemoteCommunicationServer handle this by deferring to NativeProcessProtocol::GetSharedLibraryInfoAddress (),

A few questions on this:

Q: This needs to be a loaded address value, correct?

Yes, it will return a valid load address.

Given the comments in the priority section, it seems so, and much of the shared library info on elf (rendezvous structures and such) is only available in memory form. Just wanting to check my assumption because if it is wrong, the other question is moot.

Q: Is it fair for NativeProcessProtocol to make use of the Target class?

No it isn't.

An overall goal is to limit how much NativeProcesProtocol needs to touch, which will help limit how much of lldb proper needs to be linked in on the lldb-gdbserver side. In this case, I'm finding that load address calculation (e.g. via ObjectFileELF::GetImageInfoAddress (Target *) ) ultimately need a Target to resolve a load address. I'm thinking the answer would be no.

I think we would want to avoid using Target within llgs (lldb-gdbserver).

Yes

If that's the case, I'll need to duplicate some of the Section/SectionLoadList handling. When looking at the Target set of functionality, it has a bunch of concepts that I'm thinking we don't want to have to link in just to have the load address resolution (e.g. broadcasters, execution contexts, heavy breakpoints, etc.)

Thoughts here?

This value should be a value that points you to where the loaded sections might exist in memory. If the dynamic loader for linux on a native system will always use "/proc/..." then you don't need to return a valid value. This is really a hint to the dynamic loader to tell it where it should start to look. On MacOSX, it is either the address of the "/usr/lib/dyld" mach header, or the address of a structure in dyld's data section. On a native system you can probably always rely on reading from /proc, so my guess is you can return LLDB_INVALID_ADDRESS.

We will then teach llgs to read the dynamic load info from "/proc" and return it through the packets that your guy was working on.

Greg