objdump with detached symbols
David Given
debugging information stored separately?
I have a binary --- /lib/ld-2.10.1.so, to be precise, the ELF dynamic
loader. I have the debugging symbols, stored in a different file ---
/usr/lib/debug/lib/ld-2.10.1.so. I'm trying to produce an annotated
disassembly for debugging purposes. But it appears to be highly
nonobvious how.
Does anyone have any suggestions? I've scoured the objdump man page
several times...
--
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ─────
│
│ 𝕻𝖍'𝖓𝖌𝖑𝖚𝖎 𝖒𝖌𝖑𝖜'𝖓𝖆𝖋𝖍 𝕮𝖙𝖍𝖚𝖑𝖍𝖚
│ 𝕽'𝖑𝖞𝖊𝖍 𝖜𝖌𝖆𝖍'𝖓𝖆𝖌𝖑 𝖋𝖍𝖙𝖆𝖌𝖓.
Bill Marcum
> Does anyone know how to persuade objdump to disassemble a file using
> debugging information stored separately?
>
> I have a binary --- /lib/ld-2.10.1.so, to be precise, the ELF dynamic
> loader. I have the debugging symbols, stored in a different file ---
> /usr/lib/debug/lib/ld-2.10.1.so. I'm trying to produce an annotated
> disassembly for debugging purposes. But it appears to be highly
> nonobvious how.
>
> Does anyone have any suggestions? I've scoured the objdump man page
> several times...
>
for reference, or have you found an actual bug in the loader?
Alan Curry
Bill Marcum <marcu...@bellsouth.net> wrote:
|On 2010-03-11, David Given <d...@cowlark.com> wrote:
|> Does anyone know how to persuade objdump to disassemble a file using
|> debugging information stored separately?
|>
|> I have a binary --- /lib/ld-2.10.1.so, to be precise, the ELF dynamic
|>
|Get the source code and compile it with debugging symbols. Is this just
|for reference, or have you found an actual bug in the loader?
|
I think you've missed the point. Maybe you were temporarily blinded by that
obnoxious signature.
Anyway, the question was referring to the .gnu_debuglink feature, which
seems to be not quite working with objdump. The debugging symbols are
present in /usr/lib/debug
I can see via strace that it's trying, and it actually does open the file
with the debugging symbols:
$ strace -e open objdump -dl /lib/ld-2.7.so >/dev/null
...
open("/usr/lib/debug/lib/ld-2.7.so", O_RDONLY) = 4
open("/usr/lib/debug/lib/ld-2.7.so", O_RDONLY|O_LARGEFILE) = 4
...
but it doesn't seem to be doing anything with them. This is probably an
objdump or libbfd bug.
Here's a thread where the same problem was discussed, and supposedly fixed
already: http://sourceware.org/ml/binutils/2007-06/msg00051.html
--
Alan Curry
David Given
> In article <gk2m67-...@marcumbill.bellsouth.net>,
> Bill Marcum <marcu...@bellsouth.net> wrote:
[...]
> |Get the source code and compile it with debugging symbols. Is this just
> |for reference, or have you found an actual bug in the loader?
I'm trying to debug a third-party ELF loader that is somehow getting
something wrong in such a way that it's confusing ld-linux.so. I've
tried building it myself, but the glibc build system is hairy at the
best of times, and the rtld specific build rules are even hairier ---
I'm not confident of my ability to produce a binary with debug
information that is not broken in some way.
[...]
> I can see via strace that it's trying, and it actually does open the file
> with the debugging symbols:
I hadn't thought of using strace --- ta; on my platform (Ubuntu Koala,
binutils 2.20) I can see it open the debug file, read it in, and then
attempt to load the source. By hacking symlinks in the right place so it
can find it I'm now getting interleaved source, which is hugely helpful.
But I'm still not getting any symbol information, so the only way I can
find of determining where things are is to cross-reference from the
source code. So while it's now actually *useful*, it's still not *right*...
Anyway, this is enough to let me get the job done, so thanks!
--
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ─────
│
│ life←{ ↑1 ⍵∨.^3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵ }
│ --- Conway's Game Of Life, in one line of APL