[PATCH] D118754: [DebugInfo] Always emit `.debug_names` with dwarf 5 for Apple platforms

Fri Feb 11 14:41:25 PST 2022

JDevlieghere added a comment.

In D118754#3315791 <https://reviews.llvm.org/D118754#3315791>, @dblaikie wrote:

> In D118754#3315739 <https://reviews.llvm.org/D118754#3315739>, @JDevlieghere wrote:
>
>> Both of you seem to prefer not to add a new `DebugNameTableKind` which makes me curious as to why. I'm totally fine with the suggested alternatives (I considered them myself) but having this encoded in the `NameTableKind` means we have more information in both the front and the backend so I'm interested in understanding why we would pick something that doesn't do that.
>
> Mostly for me I don't object to changing it - but that it seems like a separate thing than the DWARFv5 debug_names issue. Since it enables a bunch of functionality we didn't have before - whereas just fixing the debug_names issue in a way that's consistent with the existing MachO hardcoded apple names functionality seems like the narrower/status quo fix.

What additional functionality are you thinking of?

> If there's some desire to be able to configure debug names/accelerators on MachO, sure, happy to discuss how that might look - and yeah, having a name table kind seems plausible. (so default == debug_pubnames/pubtypes in v4, debug_names in v5, gnu == debug_gnu_pubnames/pubtypes, apple == apple_names, none == none) then changing the frontend to default to Apple on apple platforms in v4, and default on apple platforms in v5, sure.
>
> But that's a lot of changes if the only issue is missing debug_names in v5 - unless the extra flexibility is desirable, or if the existing hardcoded apple names is considered hacky/technical debt, etc.

I personally consider it to be that yes. The fact that this is broken is the result of implicit assumptions that held before we had debug_names support and then nobody noticed the discrepancy between the front and the backend. I guess subconsciously I'm worried about this breaking again which is why I'm leaning towards being more explicit.

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

https://reviews.llvm.org/D118754