ELF parsing/disassembly almost, but not quite working?

Subprojects LLDB
#1

With a few hacks and some Makefiles, I have lldb running on Linux
(I'll contribute them once I have a couple more things taken care of).
However, when I try using it, I get the following not-so-useful
results on the attached ELF-32 file:

eli@eli-laptop:~/llvmgbuild/tools/lldb$ ~/llvmgbuild/Release/bin/lldb
(lldb) file /tmp/a
Current executable set to '/tmp/a' (x86_64).
(lldb) disassemble -n main
(lldb) quit
Segmentation fault

The segfault is probably an issue in my own code, but I'm sort of
suprised the attempted disassembly leads to no output. Any ideas?

-Eli

a (6.93 KB)

#2

Well there's your problem!

The file indeed belongs to the ELF32 class (I checked), but LLDB misidentified it as an ELF64 object.

Chip

#3

The arch printed after the filename has nothing to do with the actual
file. (Probably a bug, but not really the one I'm asking about...)

-Eli

#4

Hi Eli,

Right now disassemble doesn't work until you've started execution. Gotta fix that when I get a chance.

On Mac OS X lldb defaults to assuming it is looking at an x86_64 file. If you are running it on a 32-bit file you need to explicitly invoke it 'lldb -a i386 filename'. I don't know if this will hold true on Linux as well.

J

#5

(lldb) file /tmp/a
Current executable set to '/tmp/a' (x86_64).

Well there's your problem!

The file indeed belongs to the ELF32 class (I checked), but LLDB misidentified it as an ELF64 object.

The arch printed after the filename has nothing to do with the actual
file. (Probably a bug, but not really the one I'm asking about...)

Hi Eli,

Right now disassemble doesn't work until you've started execution. Gotta fix that when I get a chance.

Ah.

I'm not anywhere near getting "run" working, so I guess I'll have to
wait for that.

On Mac OS X lldb defaults to assuming it is looking at an x86_64 file. If you are running it on a 32-bit file you need to explicitly invoke it 'lldb -a i386 filename'. I don't know if this will hold true on Linux as well.

I'll try messing with it once I get some real output.

-Eli

#6

With a few hacks and some Makefiles, I have lldb running on Linux
(I'll contribute them once I have a couple more things taken care of).

Great!

However, when I try using it, I get the following not-so-useful
results on the attached ELF-32 file:

eli@eli-laptop:~/llvmgbuild/tools/lldb$ ~/llvmgbuild/Release/bin/lldb
(lldb) file /tmp/a
Current executable set to '/tmp/a' (x86_64).

This has to do with the default architecture that is currently being set. We will need to set the following macros correctly for linux:

LLDB_ARCH_DEFAULT
LLDB_ARCH_DEFAULT_32BIT
LLDB_ARCH_DEFAULT_64BIT

These don't make as much sense in linux as they do on Mac OS X. In Mac OS X we can run either 32 or 64 bit versions of apps on the same OS install if it is 64 bit capable (85% of our Intel machines are 64 bit capable).

So we probably want to set the LLDB_ARCH_DEFAULT defines correctly for the current linux host OS with #ifdefs. This will then mean that you won't have to set the architecture unless you are doing cross debugging.

(lldb) disassemble -n main

(lldb) quit
Segmentation fault

The segfault is probably an issue in my own code, but I'm sort of
suprised the attempted disassembly leads to no output. Any ideas?

We do currently have two ReadMemory calls:

Target::ReadMemory(...)
Process::ReadMemory(...)

The Target version should be able to read memory from constant sections in executable files when we aren't running, I just need to hook it up (read the section contents from the file instead of from live memory). It shouldn't take long, I will try and get to this today as this feature is quite useful.

The rules are simple for ReadMemory:
- use the target if you know your memory might come from a constant section, or you would like us to try and read from the constant sections to avoid a ton of packets going to/from your Process plug-in.
- use the Process version if you want to read from the inferior process and skip the constant section caches.

#7

With a few hacks and some Makefiles, I have lldb running on Linux
(I'll contribute them once I have a couple more things taken care of).

Great!

However, when I try using it, I get the following not-so-useful
results on the attached ELF-32 file:

eli@eli-laptop:~/llvmgbuild/tools/lldb$ ~/llvmgbuild/Release/bin/lldb
(lldb) file /tmp/a
Current executable set to '/tmp/a' (x86_64).

This has to do with the default architecture that is currently being set. We will need to set the following macros correctly for linux:

LLDB_ARCH_DEFAULT
LLDB_ARCH_DEFAULT_32BIT
LLDB_ARCH_DEFAULT_64BIT

These don't make as much sense in linux as they do on Mac OS X. In Mac OS X we can run either 32 or 64 bit versions of apps on the same OS install if it is 64 bit capable (85% of our Intel machines are 64 bit capable).

So we probably want to set the LLDB_ARCH_DEFAULT defines correctly for the current linux host OS with #ifdefs. This will then mean that you won't have to set the architecture unless you are doing cross debugging.

This doesn't seem like the kind of thing to handle with #ifdefs,
shouldn't lldb be able to infer the architecture from the binary it is
debugging?

- Daniel

#8

This has to do with the default architecture that is currently being set. We will need to set the following macros correctly for linux:

LLDB_ARCH_DEFAULT
LLDB_ARCH_DEFAULT_32BIT
LLDB_ARCH_DEFAULT_64BIT

These don't make as much sense in linux as they do on Mac OS X. In Mac OS X we can run either 32 or 64 bit versions of apps on the same OS install if it is 64 bit capable (85% of our Intel machines are 64 bit capable).

So we probably want to set the LLDB_ARCH_DEFAULT defines correctly for the current linux host OS with #ifdefs. This will then mean that you won't have to set the architecture unless you are doing cross debugging.

This doesn't seem like the kind of thing to handle with #ifdefs,
shouldn't lldb be able to infer the architecture from the binary it is
debugging?

- Daniel

On linux yes. On Mac OS X, sometimes. If we have a universal binary we sometimes want to run i386 or x86_64, so we need to be told which one. Other times we have only one slice and the decision is easy.

#9

That makes sense. On OS X with universal binaries, it might make sense
to pick the default based on the currently running architecture. This
is similar to how the compilers work, and avoids any need for
#ifdef'ing.

- Daniel

#10

Yes, one of the parts of lldb that hasn't been fully fleshed out is the agent that will dynamically figure out this sort of thing. This sort of thing can change as the debugging session proceeds, too, for instance if you are given a 64/32 file on a 64-bit capable machine, then told to attach to a 32 bit process... So this isn't entirely trivial.

Until we get that system going, we are using some defines like this.

Jim