[all-commits] [llvm/llvm-project] 3e8ab5: [MC] Upgrade DWARF version to 5 upon .file 0

[Fangrui Song via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 3e8ab54ba072cc50e41510ec8c56f49b06cac256
      https://github.com/llvm/llvm-project/commit/3e8ab54ba072cc50e41510ec8c56f49b06cac256
  Author: Fangrui Song <i at maskray.me>
  Date:   2021-02-02 (Tue, 02 Feb 2021)

  Changed paths:
    M llvm/lib/MC/MCParser/AsmParser.cpp
    M llvm/test/MC/ELF/dwarf-file0.s
    M llvm/test/MC/ELF/dwarf-loc0.s

  Log Message:
  -----------
  [MC] Upgrade DWARF version to 5 upon .file 0

Without `-dwarf-version`, llvm-mc uses the default `MCContext::DwarfVersion` 4.

Without `-gdwarf-N`, Clang cc1as uses `clang::driver::ToolChain::GetDefaultDwarfVersion`
which is 4 on many toolchains. Note: `clang -c` can synthesize .debug_info without -g.

There is currently a MCParser warning upon `.file 0` and MCParser errors upon
`.loc 0` if the DWARF version is less than 5. This causes friction to the
following usage:

```
clang -S -g -gdwarf-5 a.c

// MC warning due to .file 0, MC error due to .loc 0
clang -c a.s
llvm-mc -filetype=obj a.s
```

My idea is that we can just upgrade `MCContext::DwarfVersion` to 5 upon
`.file 0` to make the above commands work.

The downside is that for an explicit version `clang -c -gdwarf-4 a.s`, it can be
argued that the new behavior drops the probably intended diagnostic. I think the
downside is small because in most cases DWARF version for an assembly action
should either match the original compile action or be omitted.

Ongoing discussion taking a similar action for GNU as: https://sourceware.org/pipermail/binutils/2021-January/114980.html

Differential Revision: https://reviews.llvm.org/D94882