LLDB-MI remote debugging on Linux

Hey,

I’m exploring using lldb-mi and lldb-server to remotely debug a process running on a Linux host. I’m running into an issue where lldb-mi is failing to load the ELF section headers from the remote process’s memory for certain shared libraries.

Looking at ObjectFileELF:GetSectionHeaderInfo I believe it is trying to read the section headers from <shared library base address + ELF section header offset>. As far as I’m aware, on Linux shared libraries aren’t required to be loaded in a contiguous block of memory, nor are the section headers even required to be loaded in memory.

I was wondering if this is a know issue? If so is there a bug tracking the progress?
Is remote debugging on Linux just not supported yet? Is this something that is being actively worked on?

Thanks,
Scott

Hi,

this is a known problem and somewhat embarrassing problem, but unfortunately we haven’t had time to look at that yet. The code that is doing that was added to support loading of the vdso, which is only present in the application memory (and it is a full elf file). I don’t think anybody has realized the full implications of this when it was being added. Patches fixing this would be very wellcome.

Hey Pavel,

What would be a reasonable solution?

Does having the lldb-server read the shared libraries from disk (instead of from the process’s memory) sound sensible?

Scott

What you are describing should already be the case -- lldb knows how to
download SO files through the lldb-server connection (see
PlatformPOSIX::GetFile). How are you starting lldb-server? The correct
sequence of commands should be like:
remote-host$ ./lldb-server platform *:1234

(lldb) platform select remote-linux
(lldb) platform connect connect://remote-host:1234
(lldb) ... (e.g. attach ?)

It may be possible that this has stopped working on linux as nobody tests
that, but I don't think that's likely as it works just fine on android.

This is also the reason nobody has fixed the crash you ran into, as it only
happens when something goes wrong with the module download. I am not sure
what would be the best way to fix that (if I knew, I would do it already),
but if you want to investigate, please go ahead. The only requirement I
have is that it is still able to download the vdso correctly.