Diego Novillo wrote:
Ian Lance Taylor wrote on 10/21/06 14:59:
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.)
Agreed. I don't think we'll get far if we focus too much on DWARF, as
it clearly cannot be used as a bytecode language for our purposes.
I think the bytecode issue is a red herring, because we are no longer
talking about using DWARF for the bodies of functions. DWARF is only
being used for declarations and types.
There, yes, we will need some extensions to represent things. However,
DWARF is designed to be extended, so that's no problem. I continue to
think think that using DWARF (with extensions) since it makes this
information accessible to other tools (including GDB). I think that
before there ought to be a compelling reason to abandon a strategy based
on DWARF.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
