<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 22, 2021 at 11:41 AM David Blaikie via Phabricator <<a href="mailto:reviews@reviews.llvm.org" target="_blank">reviews@reviews.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">dblaikie added a comment.<br>
<br>
In D99693#2706885 <<a href="https://reviews.llvm.org/D99693#2706885" rel="noreferrer" target="_blank">https://reviews.llvm.org/D99693#2706885</a>>, @tmsriram wrote:<br>
<br>
> In D99693#2706719 <<a href="https://reviews.llvm.org/D99693#2706719" rel="noreferrer" target="_blank">https://reviews.llvm.org/D99693#2706719</a>>, @dblaikie wrote:<br>
><br>
>> In D99693#2706501 <<a href="https://reviews.llvm.org/D99693#2706501" rel="noreferrer" target="_blank">https://reviews.llvm.org/D99693#2706501</a>>, @aprantl wrote:<br>
>><br>
>>> In D99693#2687996 <<a href="https://reviews.llvm.org/D99693#2687996" rel="noreferrer" target="_blank">https://reviews.llvm.org/D99693#2687996</a>>, @dblaikie wrote:<br>
>>><br>
>>>>> This patch does not affect C++ coroutines, since the DW_AT_specification is expected to hold the (original) linkage name.<br>
>>>><br>
>>>> So does this mean that for C++ we'll have a DW_TAG_subprogram with a DW_AT_linkage_name that doesn't match the symbol for that code in the object's symbol table?<br>
>>><br>
>>> Correct — and I would say this is probably a bug, unless we want DW_AT_linkage_name to show the "original" linkage name for purposes of matching breakpoints refering to the original name without the .resume suffix or something like that.<br>
>><br>
>> I'm a bit confused then.<br>
>><br>
>>> since the DW_AT_specification is expected to hold the (original) linkage name.<br>
>><br>
>> What's this claim ^ about/based on? What happens if it doesn't hold the original linkage name?<br>
>><br>
>> @tmsriram - I think you hit a problem with debug info linkage names not matching the symbol names in the unique linkage name work. Do you recall what the problem was when those things diverged?<br>
><br>
> TLDR; breakpoints on these functions set with "b foo" for function foo will no longer work.<br>
><br>
> In the unique linkage names work, we originally appended a suffix that could have numeric and alphanumeric characters mixed.  Such suffixes are not demangler friendly.<br>
> IIRC, In the presence of DW_AT_linkage_name, the debugger uses that when setting a breakpoint rather than DW_AT_name.   If a function foo had a linkage name say "_ZXXfoo" and didn't demangle, the debugger will not honor "b foo".<br>
<br>
Ah, so that's more about whether the name was demangleable - but I thought there was also an issue when the DW_AT_linkage_name differed from the real mangled name of the symbol, even if both names could be demangled?<br></blockquote><div><br></div><div>Isn;t there a similar issue? So if DW_AT_name is "foo" and DW_AT_linkage_name is "bar" then "break foo" is not going to work.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
Repository:<br>
  rG LLVM Github Monorepo<br>
<br>
CHANGES SINCE LAST ACTION<br>
  <a href="https://reviews.llvm.org/D99693/new/" rel="noreferrer" target="_blank">https://reviews.llvm.org/D99693/new/</a><br>
<br>
<a href="https://reviews.llvm.org/D99693" rel="noreferrer" target="_blank">https://reviews.llvm.org/D99693</a><br>
<br>
</blockquote></div></div>