This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [lto] PATCH: Read DWARF 3

Mark Mitchell wrote:
> (Kenny, see below for a thought that might influence your design for
> function bodies.)
> This patch makes the LTO front end do something vaguely substantive.
> In particular, compiling:
>    int i;
> with "gcc -g -c", and then recompiling the resulting object file with
> the LTO front end, does indeed produce an object file which defines
> "i".  (Sadly, the variable is moved from COMMON to BSS, so it's not
> quite getting even this simple task right, but you must walk before
> you run.)
> Perhaps somewhat more amusing is that:
>   === a.c ===
>   int a;
>   === b.c ===
>   int b;
>   $ gcc -c -g a.c b.c
>   $ lto1 a.o b.o
> does result in an a.s containing both "a" and "b".  There's nothing
> sophisticated going on -- we don't check for conflicts, try to merge
> anything, etc. -- but we are in fact squishing two object files
> together.  (And helpfully putting *both* variables in the wrong
> section.)
> Most of this patch is infrastructure for reading DWARF; that's now
> mostly complete.  The most obvious missing bit -- to me -- is that we
> need a DIE cache so that multiple references to the same DIE do not
> result in reading the same information multiple times.  Once we add
> the bits to merge duplicate entries across translation units, it would
> probably *work* to read the entries multiple times, but it would be
> unbelievably foolish.
> Kenny, Jim Blandy suggested that it might make sense for us to use
> DWARF for the bodies of functions as well as for declarations.  The
> idea here would be to define a bunch of new DWARF tags and attributes
> to represent TREE nodes.  So, this is a syntactic choice (i.e., format
> of bits on disk), not a semantic choice about what the content actuall
> is.  There's nothing magic about the idea, but it would let us
> leverage a pre-existing file format that (a) provides a reasonable
> representation for tree-structured data (like TREE), (b) which has
> some encoding tricks for compactness, and (c) for which we already
> have readers, writers, and file dumpers.  So, I think it's an idea
> worth thinking about.
Lets say that I do this.  Does each function go in it's own dwarf
section or do I cram all of the function bodies in the same section?
> This patch also gets us to the point where I think other people can
> begin to usefully contribute stuff, like (in order from easier to
> harder):
> * fill in the attr_classes table in lto_read_form
> * add support for reading DWARF forms not yet handled
> * write DIE readers to generate trees for more kinds of stuff, or, as
>   a first step, write do-nothing stub functions for the various DIEs
>   using the template for the existing readers
> I plan to work next on the infrastructure for merging across
> translation units (using placeholder routines that don't really do any
> merging) so that we have the right structure for the reader.
> --
> Mark Mitchell
> CodeSourcery
> (650) 331-3385 x713

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]