[PATCH] D100440: [Debug-Info] DW_AT_export_symbols shouldn't be generated before version-5 of DWARF.

ChenZheng via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Apr 20 01:40:21 PDT 2021


shchenz added a comment.

In D100440#2698987 <https://reviews.llvm.org/D100440#2698987>, @dblaikie wrote:

> In D100440#2698501 <https://reviews.llvm.org/D100440#2698501>, @jhenderson wrote:
>
>> In D100440#2688023 <https://reviews.llvm.org/D100440#2688023>, @dblaikie wrote:
>>
>>> @aprantl @probinson @jhenderson - any of you folks want this in older versions? I think this is for C++ inline namespaces - so if you used a modern C++ standard library (that uses inline namespaces like "std::__1::basic_string", etc) users would have to use these extra qualifiers when naming types, functions, etc. Not unworkable, but a bit inconvenient.
>>
>> I'm not the right person to ask, but I wouldn't expect a DWARF v4 consumer to be able to recognise a DWARF v5 attribute in general, and therefore we shouldn't be using emitting it in older cases. @probinson or maybe @jmorse will probably have a better insight here.
>
> Generally we figure emitting new tags/attributes is OK, because consumers are meant to ignore them if they don't recognize them - and some consumers can recognize them as an extension. (such as lldb)
>
> This conversation's gotten fragmented over a bunch of reviews, unfortunately - but it sounds like the direction it's headed is that maybe -gstrict-dwarf will be wired up to do all this pedantry/not emit things from future standards, and DBX tuning will opt in to -gstrict-dwarf mode.

Thanks for the explanation @dblaikie Yes, we just add `-gstrict-dwarf` support in D100809 <https://reviews.llvm.org/D100809> and D1000826. This option is turned off by default and only enabled for DBX.

I think we also need to change this patch accordingly. @Esme


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D100440/new/

https://reviews.llvm.org/D100440



More information about the llvm-commits mailing list