Debuginfo + addr2line

[Mike Perry]

Hey, I'm working on building symbol resolution into my malloc
debugger (NJAMD), and I was wondering if anyone had any information on
how debuginfo files are built. I'm currently using addr2line to look
up symbols for me, but it seems as though the mods to support
debuginfo files were only made to gdb, and not to binutils.

So I guess I have two questions:

1. Are there any plans to patch addr2line to support debuginfo files?

2. If not, where can I find information on how these things are
generated/formatted so as to attempt a patch to addr2line myself? I've
scoured the web but seem to be unable to find much of any use.


Thanks,

[Roland McGrath]

The binutils programs really should be extended to be able to use debuginfo
files. But another thing that binutils should have that's easier to do
first is a way for objcopy to put the separated files back together so you
can use the existing tools on the result of that.

[Mike Perry]

Post by Roland McGrath
The binutils programs really should be extended to be able to use debuginfo
files. But another thing that binutils should have that's easier to do
first is a way for objcopy to put the separated files back together so you
can use the existing tools on the result of that.

Do you have any idea where I can get some info on how this works? Even
if you could just point me to the original patch or something for gdb
maybe I could figure it out and try to hack something up..

[Mike Perry]

Post by Roland McGrath
The binutils programs really should be extended to be able to use debuginfo
files. But another thing that binutils should have that's easier to do
first is a way for objcopy to put the separated files back together so you
can use the existing tools on the result of that.

Do you have any idea where I can get some info on how this works? Even
if you could just point me to the original patch or something for gdb
maybe I could figure it out and try to hack something up..

[Roland McGrath]

Post by Mike Perry
Do you have any idea where I can get some info on how this works?

Well, read the source. Basically, the debug information all lives in
special ELF sections, and the debuginfo files contain those. There are
some further subtlties to it. Just use the tools (eu-strip -f,
objcopy/strip --only-keep-debug), or look at -debuginfo packages, and you
will see what the sections look like.

Post by Mike Perry
Even if you could just point me to the original patch or something for
gdb maybe I could figure it out and try to hack something up..

If you look at current gdb sources and search for "separate_debug",
you will see all the code that deals with it.

[Mike Perry]

Post by Roland McGrath

Post by Mike Perry
Do you have any idea where I can get some info on how this works?

Well, read the source. Basically, the debug information all lives in
special ELF sections, and the debuginfo files contain those. There are
some further subtlties to it. Just use the tools (eu-strip -f,
objcopy/strip --only-keep-debug), or look at -debuginfo packages, and you
will see what the sections look like.

Ah, this should help. The problem is my first encounter with these
files was the debuginfo rpms, and rpmbuild creates these
automagically with little to no documentation on the process.

Post by Roland McGrath

Post by Mike Perry
Even if you could just point me to the original patch or something for
gdb maybe I could figure it out and try to hack something up..

If you look at current gdb sources and search for "separate_debug",
you will see all the code that deals with it.

Will do, thanks much.

[Mike Perry]

Post by Roland McGrath

Post by Mike Perry
Do you have any idea where I can get some info on how this works?

Well, read the source. Basically, the debug information all lives in
special ELF sections, and the debuginfo files contain those. There are
some further subtlties to it. Just use the tools (eu-strip -f,
objcopy/strip --only-keep-debug), or look at -debuginfo packages, and you
will see what the sections look like.

Ah, this should help. The problem is my first encounter with these
files was the debuginfo rpms, and rpmbuild creates these
automagically with little to no documentation on the process.

Post by Roland McGrath

Post by Mike Perry
Even if you could just point me to the original patch or something for
gdb maybe I could figure it out and try to hack something up..

If you look at current gdb sources and search for "separate_debug",
you will see all the code that deals with it.

Will do, thanks much.

[Mike Perry]

Hey, I'm working on building symbol resolution into my malloc
debugger (NJAMD), and I was wondering if anyone had any information on
how debuginfo files are built. I'm currently using addr2line to look
up symbols for me, but it seems as though the mods to support
debuginfo files were only made to gdb, and not to binutils.

So I guess I have two questions:

1. Are there any plans to patch addr2line to support debuginfo files?

2. If not, where can I find information on how these things are
generated/formatted so as to attempt a patch to addr2line myself? I've
scoured the web but seem to be unable to find much of any use.


Thanks,

[Roland McGrath]

The binutils programs really should be extended to be able to use debuginfo
files. But another thing that binutils should have that's easier to do
first is a way for objcopy to put the separated files back together so you
can use the existing tools on the result of that.

[Roland McGrath]

Post by Mike Perry
Do you have any idea where I can get some info on how this works?

Well, read the source. Basically, the debug information all lives in
special ELF sections, and the debuginfo files contain those. There are
some further subtlties to it. Just use the tools (eu-strip -f,
objcopy/strip --only-keep-debug), or look at -debuginfo packages, and you
will see what the sections look like.

Post by Mike Perry
Even if you could just point me to the original patch or something for
gdb maybe I could figure it out and try to hack something up..

If you look at current gdb sources and search for "separate_debug",
you will see all the code that deals with it.