On Sun, Jul 27, 2008 at 7:41 PM, Daniel Berlin <[EMAIL PROTECTED]> wrote: > On Sun, Jul 27, 2008 at 3:10 PM, Mark Mitchell <[EMAIL PROTECTED]> wrote: >> Daniel Berlin wrote: >> >>>> I agree that, at least in principle, it should be possible to emit the >>>> debug >>>> info (whether the format is DWARF, Stabs, etc.) once. >>> >>> No, you can't. >>> You would at least have to emit the variables separate from the types >>> (IE emit debug info twice). >> >> Yes, of course; that's what everyone is talking about, I think. "Emit" here >> may also mean "cache in memory some place", rather than "write to a file". >> It could mean, for example, fill in the data structures we already use for >> types in dwarf2out.c early, and then throw away the front-end type >> information > Okay, then let us go through the options, and you tell me which you > are suggesting: > > If you assume LTO does not have access to the front ends, your options > look something like this: > > When you first compile each file: > Emit type debug info > Emit LTO > > When you LTO them all together > Do LTO > Emit variable debug info > > Under this option, "Emit variable info" requires being able to > reference the types. If you've lowered the types, this is quite > problematic. So either you get to store label names for the already > output type debug info with the variables (so you can still reference > the type you output properly when you read it back in). This is > fairly fragile, to be honest. > Another downside of this is that you can't eliminate duplicate types > between units because you don't know which types are really the same > in the debug info. You have to let the > > Another option is: > > When you first compile each file: > Emit type debug info > Emit partial variable debug info (IE add pointers to outputted types > but not to locations) > Emit LTO > > When you LTO them all together: > Do LTO > Parse and update variable debug info to have locations > Emit variable debug info > > This requires parsing the debug info (in some format, be it DWARF or > some generic format we've made up) so that you can update the variable > info's location. > As a plus, you can easily update the types where you need to. > Unlike the first option, because you understand the debug info, you > can now remove all the duplicate types between units without having to > have the linker do it for you. > > Unless you link in every single frontend to LTO1 (Or move a lot to > the middle end), there is no way to do the following: > > When you first compile each file: > Emit LTO > > When you LTO them all together: > Emit type debug info > Do LTO > Emit variable debug info > > If you don't want to link the frontends, you could also get away with > moving a lot of junk to the middle end (everything from being able to > distinguish between class and struct to namespaces, the context of > lexical blocks) because debug info outputting uses language specific > nodes all over the place right now.
Sorry, hit send a little too early. This option also requires being able to serialize language specific nodes (or again, you move things like namespaces and other language specific contexts to the middle end), and to stop throwing this stuff out at the point we do right now. I'm not sure what most LTO compilers do. At least when i was at IBM, XLC simply output the debug info in a generic format (it was part of the definition of wcode), parsed it back in, updated it, and transformed it into DWARF/etc at the backend. This is a variant of the second option above. Again, i'm not saying it's the best option, and in fact i'm very curious what most compilers do.
