r184276 - Debug Info: support for gdwarf-2 gdwarf-3 gdwarf-4

[David Blaikie]

+Dan

On Wed, Jun 19, 2013 at 8:57 AM, Eric Christopher <echristo at gmail.com> wrote:
> Hi Manman,
>
> Few issues with this patch:
>
>> Debug Info: support for gdwarf-2 gdwarf-3 gdwarf-4
>>
>> These options will add a module flag with name "Dwarf Version".
>> The behavior flag is currently set to Warning, so when two values disagree,
>> a warning will be emitted.
>>
>
> I don't think a module flag is the way we want to go about this, I
> think it should be an attribute on the compile unit created.

Hmm, I could've sworn we (Eric, Dan, and myself) in person a couple of
weeks ago & decided that a module flag was the way to go - but I'm not
100% sure that's how the conversation concluded & I'm also not sure I
can reconstruct all the arguments.

I think it went something like: we'll need the module-level
functionality anyway, and it'll be able to report
errors/incompatibilities in a uniform way that users will be used to,
whereas if we did this down in debug info we wouldn't be able to use
such error reporting if there are "incompatible" dwarf version
requests. (I suppose there might not be - in which case it'd be "min"
or "max" essentially and even then, presumably, having the common
module functionality able to handle that for us seems reasonable/nice)

> Few constraints there:
>
> a) this means that we just check the compile unit as we create up the
> DIE and we don't have to check the module.

I'm not sure that's a huge change - and we'd still have to have some
code resolve the difference between different modules & presumably
rewrite the compile unit of each one to bring it up to whatever the
One True dwarf version is that we'll be using for this build, no? Or
are you expecting to generate some DWARF-N for some compile units in
the same compilation and DWARF-M for others?

> b) at LTO time we can link and generate debug info for modules that
> may (due to historic, or otherwise silly reasons) have used two
> different values for dwarf level without a warning,

I'm not sure how we settled on this issue - whether the module
handling should just bump everything up to the "minimum compatible"
version (floor of DWARF-4 or whatever, otherwise the max of all the
specified versions from the different CUs).

> c) at LTO time we'll likely want to constrain to a minimum dwarf
> version that contains ref addr so that we can minimize, but this is by
> no means required,

Fair enough, so maybe the 'floor' above isn't required.

> d) it matches how linkers actually link debug information
>
> Also:
>
>> +  else if (Opts.getDebugInfo() != CodeGenOptions::NoDebugInfo)
>> +    // Default Dwarf version is 3 if we are generating debug information.
>> +    Opts.DwarfVersion = 3;
>>
>
> We want 4 here I believe, or even a level for "latest" with all of the
> bells and whistles. 4 is a likely sufficient start though since we'd
> have to define what "all the bells and whistles" means :) Or, as an
> alternate question, "why 3?"
>
> Thanks!
>
> -eric
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits