This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Question about LTO dwarf reader vs. artificial variables and formal arguments
- From: Ian Lance Taylor <iant at google dot com>
- To: Steven Bosscher <stevenb dot gcc at gmail dot com>
- Cc: Sandra Loosemore <sandra at codesourcery dot com>, gcc at gcc dot gnu dot org
- Date: 21 Oct 2006 11:59:12 -0700
- Subject: Re: Question about LTO dwarf reader vs. artificial variables and formal arguments
- References: <200610211835.40973.steven@gcc.gnu.org>
Steven Bosscher <stevenb.gcc@gmail.com> writes:
> I haven't really been following the whole LTO thing much, but if I understand
> correctly, the goal is to reconstruct information about declarations from
> DWARF information that we write out for those declarations. If that's the
> case, I wonder how LTO will handle artificial "variables" and formal argument
> lists.
I think it is a mistake to focus on DWARF details too much. We simply
need some mechanism to write trees into an object file and to read
them back in. That mechanism can be anything.
We are using DWARF on the theory that it will be simpler because DWARF
readers and writers already exist (I don't buy that argument myself,
but, whatever). But it is clearly impossible to represent everything
we need to represent in DWARF. So we need to extend DWARF as
necessary to represent all the tree details.
That is, we are not going to write out DWARF. We can't, because DWARF
is not designed to represent all the details which the compiler needs
to represent. What we are going to write out is a superset of DWARF.
And in fact, if it helps, I think that we shouldn't hesitate to write
out something which is similar to but incompatible with DWARF.
In general reading and writing trees is far from the hardest part of
the LTO effort. I think it is a mistake for us to get too tied up in
the details of how to represent things in DWARF. (I also think that
we could probably do better by defining our own bytecode language, one
optimized for our purposes, but it's not an issue worth fighting
over.)
Ian