Right now we package the debuginfo so it contains only the DWARF debug information, but some utilities can't work with that. If we put the full modules with debug info in the package then everything should work, at the cost of making the package about 14MB larger. Is there any reason not to do this? (i686 debuginfo is about 175MB now.)
On Mon, 2007-04-02 at 14:05 -0400, Chuck Ebbert wrote:
Right now we package the debuginfo so it contains only the DWARF debug information, but some utilities can't work with that. If we put the full modules with debug info in the package then everything should work, at the cost of making the package about 14MB larger. Is there any reason not to do this? (i686 debuginfo is about 175MB now.)
Which utilities don't work with just DWARF by the way?
josh
Josh Boyer wrote:
On Mon, 2007-04-02 at 14:05 -0400, Chuck Ebbert wrote:
Right now we package the debuginfo so it contains only the DWARF debug information, but some utilities can't work with that. If we put the full modules with debug info in the package then everything should work, at the cost of making the package about 14MB larger. Is there any reason not to do this? (i686 debuginfo is about 175MB now.)
Which utilities don't work with just DWARF by the way?
objdump for one - I can't get a mixed source/disassembly listing for modules. This makes debugging oopses inside of modules a lot harder than it needs to be.
I'm not positive everything will work, i.e. systemtap et al that do deal with separate debuginfo properly now. We could test it. OTOH, it may take less time than mucking with the build and testing the results for me to write an "unstrip" to paste together what was separated at build time. And that kludge is more of an explicit kludge rather than yet more obscure weirdness because of tool inadequacies that will eventually go away.
Thanks, Roland
Roland McGrath wrote:
I'm not positive everything will work, i.e. systemtap et al that do deal with separate debuginfo properly now. We could test it. OTOH, it may take less time than mucking with the build and testing the results for me to write an "unstrip" to paste together what was separated at build time. And that kludge is more of an explicit kludge rather than yet more obscure weirdness because of tool inadequacies that will eventually go away.
What we really need is eu-objdump. Apparently the unit-at-a-time compiler option breaks the old one, in addition to it not handling the separate debug info.
What we really need is eu-objdump. Apparently the unit-at-a-time compiler option breaks the old one, in addition to it not handling the separate debug info.
We have one upstream, but without a disassembler (yet). Do you have a reference to the unit-at-a-time problem with binutils' disassembler?
Roland McGrath wrote:
What we really need is eu-objdump. Apparently the unit-at-a-time compiler option breaks the old one, in addition to it not handling the separate debug info.
We have one upstream, but without a disassembler (yet). Do you have a reference to the unit-at-a-time problem with binutils' disassembler?
Have to check with Andi Kleen, that keeps complaining, but was along the lines that the source gets unreadable, sorry for the lack of details, will talk to Andi when he gets back online.
- Arnaldo
kernel@lists.fedoraproject.org
-
Arnaldo Carvalho de Melo -
Chuck Ebbert -
Josh Boyer -
Roland McGrath