Ah sorry hadn't noticed this one was abandoned. Never mind.
This patch is for generating DWARF-64 format for raw assembler source. Why is that an interesting case? I could see wanting to emit a .debug_info section for higher level languages in DWARF-64 format, but that is not what this patch does.
The test is verifying that llvm-mc can emit a DWARF-64 line table describing assembler source that does not have any .loc directives in it. That's not really the interesting case; the interesting case is assembler source that *does* have .loc directives in it, because that's the path that most compilations will actually use. Describing assembler source really doesn't need to support DWARF-64.
Some of these changes are specific to cases where we are emitting DWARF describing assembler source; I don't see any reason to support DWARF-64 for those cases. (In general, any functions with GenDwarf in the name are for this case.) Also in most cases the DWARF version for sections describing assembler source are hard-coded to DWARF version 2, which did not define the DWARF-64 format.
This patch modifies EmitGenDwarfAranges(), which is used only when the assembler is generating DWARF to describe the assembler source.
I can't imagine anyone is really writing large enough assembler that they need to emit DWARF-64 format. What is the motivation here?
With one test change
Add a command line option
Looks good - thanks!
Patches without tests shouldn't be approved - and at least the usual/rough metric I use for patch approval is (most often - unless I'm reviewing the work of the code owner in any area who wants a second opinion, etc) - I approve it if I'd be willing to commit a similar patch without approval (with post-commit review - ie: I'm fairly sure this is the right direction and folks will agree with me, or minor changes can be handled in post-commit iteration). Otherwise "approval" gets muddied as to whether it means "you can now commit this" versus "I think this is good but you should wait for someone more authoritative to say 'yes' before it's committed" (usually folks on the project call out the latter explicitly - sometimes using Phab's "approve" sometimes not).
CI error is unrelated.