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

[Manman Ren]

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?

Thanks,
Manman
> 
> Read your new email and I can go with that modulo the above :)
> 
> -eric

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130226/65e050df/attachment.html>