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

[Eric Christopher]

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?

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