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

[Paul Robinson via Phabricator via llvm-commits]

probinson added a comment.

Catching up on this, sorry...

I believe the file number in `.loc` has to be defined by a preceding `.file` directive; at least, a .s file with a bare `.loc 1 1 1` gets an error about "unassigned file number 1" from as.  So, `.file 0` is the only special case with regards to picking a DWARF version.

I'm not keen on defining an assembler directive that GNU as does not also support.

I don't mind upgrading MC's opinion of the *defaulted* DWARF version, based on the existence of a `.file 0` directive.  I'd be less happy about `llvm-mc -dwarf-version 4 foo.s` emitting DWARF v5 line tables, because the user asked for something very specifically, in a developer tool.

Clang does not provide a user-level assembler tool; assembler source is passed through Clang itself.
`clang -c -g foo.s` implies that foo.s has no embedded DWARF directives, and the user wants the DWARF to describe the assembler source itself.  If we do see DWARF directives, then we abandon the idea of describing the assembler source, and take the embedded DWARF directives as determining what to do.  I think I would not be opposed to emitting DWARF v5 in this case, if we saw a `.file 0`.

The counter-argument to that last bit is that we do obey the specified version if there is one; i.e., `clang -c -gdwarf-3 foo.s` will emit DWARF v3 line tables, not v4.  This suggests that if we see a `.file 0` we should complain; and then why shouldn't we complain in the simple `clang -g` case?

But if the .s file has a `.file 0` directive (or an `md5` keyword, or anything else new in v5) that implies the .s file was generated with v5 in mind, and so producing an object file with v5 line tables would not be a practical problem.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94882