[PATCH] D94882: [MC] Upgrade DWARF version to 5 upon .file 0

Tue Jan 19 00:55:12 PST 2021

jhenderson added a comment.

In D94882#2506051 <https://reviews.llvm.org/D94882#2506051>, @MaskRay wrote:

> In D94882#2506029 <https://reviews.llvm.org/D94882#2506029>, @jhenderson wrote:
>
>> In D94882#2505699 <https://reviews.llvm.org/D94882#2505699>, @dblaikie wrote:
>>
>>> In D94882#2504207 <https://reviews.llvm.org/D94882#2504207>, @jhenderson wrote:
>>>
>>>> Maybe a silly suggestion (and one that would need more discussion on the mailing lists), but why not just change the default version to 5 more widely? How often do people deliberately deviate from the default DWARF version in practice? To me, the proposed change feels like a bit of a hack for what is likely fairly unusual usage, and is only temporary, since likely most toolchains will want to change to DWARF v5 at some point going forward.
>>>
>>> ie: you're suggesting users needing to use DWARFv4 line tables would access that functionality with a flag passed to the assembler (as they do today if they want to opt in to DWARFv5)?
>>
>> Right, yes, that's what I'm suggesting.
>>
>>> I think part of the problem is that people aren't used to (ie: build systems and other infrastructure isn't designed for) having to pass a dwarf version to their assembler - the line table format hasn't changed since DWARFv2. So if you have run `-gN -S`, you can pass the resulting file to the compiler/assembler without any flags. So even if we switch the default - then people who aren't ready to switch to DWARFv4 are going to be in a possibly difficult situation of trying to teach their build system how to pass the appropriate flags to the assembler, etc.
>>>
>>> I think maybe the way to think about it is that there wouldn't be a default DWARF version - it could always be determined by the presence/absence of a file 0.
>>
>> I'm concerned about relying on what is essentially a minor detail of the specification, for a couple of reasons:
>>
>> 1. What if the `.file 0` directive isn't present for future DWARF versions (e.g. DWARFv6), for whatever reason? You might have some code that is generated expecting DWARFv6, yet the assembler will end up generating (or at least trying to generate) DWARFv4 output. It seems like relying on a detail like this is fragile and not particularly future-proof.
>
> Perhaps add an assembly directive when that that time comes?

What's stopping us adding an assembly directive now? The sooner we add it, the less chance there'll be old assembly kicking around that causes problems.

>> 1. To most users, it won't be clear that `.file 0` means DWARFv5 and no `.file 0` means DWARFv4. This could lead to potential confusion when the DWARF doesn't contain the expected information.
>
> Looks like they have made the change to GNU as: https://sourceware.org/bugzilla/show_bug.cgi?id=27195

As noted here, I think that upgrade is a mistake personally, and that an assembly directive would be a clearer and cleaner solution. However, I suppose there is the question of what to do about assembly files without the proposed directive, and that might be to do the upgrade in that case, I guess, although I'm not sure whether that's a real case that needs supporting.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94882