Re: [RFC] Aggregate mapping

[Daniel Jacobowitz <drow at false dot org>]

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