DWARF-5 has two line-table features that are probably best handled by extensions to the .file directive in the assembler. (a) provide an MD5 checksum of the source file, as a more reliable way to verify whether the source file has changed since compilation. (b) explicitly provide the root source file as "file #0" in the file table, making the line table fully independent of the .debug_info section. The existing .file directive syntax is: .file filenumber [ "directory" ] "path" To support MD5 checksums computed by the compiler, I propose making the syntax be .file filenumber [ "directory" ] "path" [ md5 checksum ] where 'md5' is a keyword and checksum is the 128-bit integer checksum, which can be expressed in the same ways that the .octa directive allows. If all .file directives provide an MD5 checksum, then the line-table header will include the provided values using DW_LNCT_MD5. If not all .file directives provide the MD5 clause, then DW_LNCT_MD5 should be omitted (as DWARF does not provide a way to give MD5 values for some files but not others in the same compilation unit). To support the root file, I propose that the filenumber is allowed to have the value 0 (currently must be >= 1). If no ".file 0" appears, then replicate the file #1 entry as file #0. This permits the same assembler source to be used to generate either DWARF-4 or DWARF-5 without complaint. I have implemented these features in the LLVM assembler. In response to a question on the binutils list, no I am not offering to implement the features in the GNU assembler. But it seems like a good idea for both assemblers to support the same syntax.
A couple of notes to bring this BZ up to date: * There is a proposal to add a hash of the compilation unit source to the DW_TAG_compile_unit here: http://dwarfstd.org/ShowIssue.php?issue=171216.1 * If the assembler sees multiple, different md5 checksum values, it should issue a warning message, but not an error. It is possible that there are valid reasons for the mismatch. It may even be useful to add an option to suppress the warning.
(In reply to Nick Clifton from comment #1) > * There is a proposal to add a hash of the compilation unit source to the > DW_TAG_compile_unit here: http://dwarfstd.org/ShowIssue.php?issue=171216.1 That's a proposal to hash the DWARF, not the source, as I read it.
Created attachment 11091 [details] Sample .s and .o Attaching a zip of a .s and .o file produced by Clang with -gmlt. Note that file 0 and file 2 are the same, this is because Clang doesn't fully understand the notion of file 0 yet. But it should be enough to show how the line table header would work.
In addition to the extensions noted in comment 0, of course the .loc directive would also need to accept file number 0 if there is one. My impression had been that file #0 was implicitly the root file as described in the DW_TAG_compile_unit, but reading the DWARF 4 spec closely, it does not actually say that file #0 is valid (it is clear that directory 0 is valid). So, .loc should accept file number 0 only when the assembler is generating a DWARF-5 line table.
As part of the experimental two-level line tables support, I implemented a bunch of DWARF-5 line table support in gas. It's on the users/ccoutant/two-level-line-tables branch. I can port the relevant parts over to trunk, and add the new .file directive.
(In reply to Cary Coutant from comment #5) > I can port the relevant parts > over to trunk, and add the new .file directive. That would be much appreciated - thank you. Do you want me to delay the 2.31 branch for this ? Cheers Nick
>> I can port the relevant parts >> over to trunk, and add the new .file directive. > > That would be much appreciated - thank you. > > Do you want me to delay the 2.31 branch for this ? I've still got a couple of things for gold I'm trying to get in by tomorrow, so I won't be able to get started on this until next week. It's up to you -- how important do you think this is for 2.31? -cary
Hi Cary. > I've still got a couple of things for gold I'm trying to get in by > tomorrow, so I won't be able to get started on this until next week. > It's up to you -- how important do you think this is for 2.31? Not at all. :-) My theory is that if you are working with cutting edge features like DWARF-5 enhancements then you are able to work with development versions of the binutils, and so you do not expressly need a feature to be in an official release before you can use it. Cheers Nick