On Sun, Jun 10, 2007 at 12:56:26PM -0400, Jim Tison wrote: > option or standalone program. I'm proposing to create a standalone program, > as > I don't know enough about gcc internals to force such maps to be generated > during compilation ... I'm not certain this would be appropriate, anyway. > OTOH, > I can't be the first to propose solving this problem.
I'm pretty sure the Linux kernel people have a similar tool, that they use to find padding holes in data structures. Aha, here it is: http://lwn.net/Articles/206805/ > AFAICT, the only accurate source data for such an aggregate map would be > DWARF > DIE entries. Congratulations - I've seen people come up with all sorts of ways to do this, but you've found the correct one :-) Use the debug information; it's standardized and we have high incentive to keep it correct. > I've done some reading of the DWARF-2 and DWARF-3 standards. What I see > emitted > as DWARF in gcc-4.1.x is marked as DWARF-2; but I'm told that gcc properly > emits DWARF-3. Should I even check the version? Will I need to vary > processing > features by gcc level? The version number found in .debug_info is not necessarily the same as the version number of the standard. I believe the 2 vs 3 controls whether one field is a byte or a uleb128, and another similar format change. I recommend you accept version 2 or version 3, and handle any new attributes that you're concerned about whether they appeared in DWARF-2 or DWARF-3. > Since I'm targeting all three ELF object types, I'm thinking I have to start > reading the sections .debug_info and .debug_abbrev at the DWARF CU level, and > build a tree of CU-related data. I've actually started this bit of code and > am > somewhat happy with test results so far. Or just use libdwarf? Really - it already does this. I've been planning to write Python bindings for it, too, but never had the time. The more of this you reinvent, the more places you might make a mistake. > Nor am I planning to use libelf: it's too straightforward to find the ELF > sections I need and to read the ELF header. Use of libelf seems too > top-heavy, > although elf.h is very valuable to me. If you write more complicated tools, you will want libelf later - you might need to get at relocation data. -- Daniel Jacobowitz CodeSourcery
