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

[Eric Christopher]

On Wed, Feb 27, 2013 at 10:52 AM, Manman Ren <mren at apple.com> wrote:

>
> 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.
>
>
It's DarwinGDBCompat. All of the options are at the top of DwarfDebug.cpp.
Out of curiosity is it needed for gdb? In other words, is moving it from
the member to the variable enough?

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