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

[Eric Christopher]

>> 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)
>

Right, but that pretty much contradicts how linkers deal with them
today - it's perfectly compatible to link them without warning.

>> 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?

Only at LTO time and only up to a minimum of 3. Otherwise, I'm
perfectly fine with generating differing values of dwarf for each
compile unit.

> 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.
>

*nod* Basically the way we're doing LTO is going to require
inter-compile unit references. Other than that there's no real need to
do any munging of the value at all. Hence me figuring to just leave it
on each compile unit and keep the logic on what to emit in the compile
unit itself.

It probably comes down to simple preference really there's nothing
compelling about either way unless we want to explicitly warn people
and that'd be creating a new warning for "little" reason and it might
be surprising for people that were previously getting no warnings with
normal compilation moving to LTO. That said, maybe they'll be
surprised when they get inter-compile unit references.

*shrug*

-eric


>> 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