[llvm] r176143 - Debug Info: for static member variables, add AT_MIPS_linkage_name to the

[Manman Ren]

On Feb 27, 2013, at 10:31 AM, Eric Christopher wrote:

> 
> 
> 
> On Wed, Feb 27, 2013 at 9:59 AM, Manman Ren <mren at apple.com> wrote:
> 
> On Feb 26, 2013, at 5:59 PM, Eric Christopher <echristo at gmail.com> wrote:
> 
>> 
>> 
>> 
>> On Tue, Feb 26, 2013 at 5:55 PM, Manman Ren <mren at apple.com> wrote:
>> 
>> On Feb 26, 2013, at 5:18 PM, Eric Christopher <echristo at gmail.com> wrote:
>> 
>>> 
>>> which seems to have the linkage name on the TAG_variable die and nowhere else (for this testcase) which partially seems what you're doing (adding it to the TAG_variable).
>>> 
>>> 
>>> Just noticed, FWIW, that gcc 4.8 is using the newer DW_AT_linkage_name from dwarf-4 2.22 for the linkage names which obviously won't work here, but it gives a definition of:
>>> 
>>> "Some language implementations, notably C++ and similar languages, make use of implementation defined names within object files that are different from the identifier names (see Section 2.15) of entities as they appear in the source. Such names, sometimes known as mangled names, are used in various ways, such as: to encode additional information about an entity, to distinguish multiple entities that have the same name, and so on. When an entity has an associated distinct linkage name it may sometimes be useful for a producer to include this name in the DWARF description of the program to facilitate consumer access to and use of object file information about an entity and/or information that is encoded in the linkage name itself.
>>> 
>>> A debugging information entry may have a DW_AT_linkage_name attribute whose value is a null-terminated string describing the object file linkage name associated with the corresponding entity.
>>> 
>>> Debugging information entries to which DW_AT_linkage_name may apply include: DW_TAG_common_block, DW_TAG_constant, DW_TAG_entry_point, DW_TAG_subprogram and DW_TAG_variable."
>>> 
>>> 
>>> but if gdb needs the linkage name on the variable and on the member then we should probably go ahead and put it on the member as a compatibility option and on the variable always (and updating the comments/testcases appropriately).
>> 
>> Without any of my checkins, we used to put AT_linkage_name on the member, will changing it to a compatibility option cause issues on debuggers that are not ready for dwarf-4?
>> 
>> 
>> Well, keep the spelling the same as DW_AT_MIPS_linkage_name for now, I'll worry about that part. I was mostly thinking about not putting it on the member similarly to how we've got it for subprogram DIEs (DwarfCompileUnit.cpp) where we had a similar sort of issue. Was hoping you'd let me know if things would fail with darwin gdb with that change. This way we're leaving out the compatibility language unless we need it on the TAG_member since putting it on the TAG_variable matches with what we've got from dwarf-4. If we need to have something compatible that's fine too but wanted to have it on the notionally correct DIEs first and then add compatibility from there.
> Any pointer on how to add a compatibility option? Do we need a separate option for AT_MIPS_linkage_name on TAG_member? If yes, any suggestion on the name?
> 
> There's already an option for compatibility with old darwin gdb, I figure we'd just use that?
Great, what is the existing option? I can guard the MIPS_linkage_name on TAG_member with that option.

Thanks,
Manman
> 
> -eric 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130227/913542f5/attachment.html>