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

[Eric Christopher]

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

>
> On Feb 27, 2013, at 11:03 AM, Eric Christopher wrote:
>
>
>
>
> 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?
>
>
> For darwin gdb, moving it from member to variable is not enough.
> GDBs that support gcc 4.7 should be okay with moving from member to
> variable.
> But I am not sure about other versions of GDB.
>
>
Sweet, thanks, just checking. Yes please put it under an option for now.

Thanks!

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