Summary: | dwarf-5 allows for .file 0 | ||
---|---|---|---|
Product: | binutils | Reporter: | Nick Desaulniers <ndesaulniers> |
Component: | gas | Assignee: | Not yet assigned to anyone <unassigned> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | dblaikie, nickc, paul_robinson |
Priority: | P2 | ||
Version: | 2.35 | ||
Target Milestone: | --- | ||
Host: | Target: | ||
Build: | Last reconfirmed: | 2020-03-03 00:00:00 | |
Attachments: |
foo.s
Assembled form of foo.s |
Description
Nick Desaulniers
2020-02-28 22:55:59 UTC
Also, documentation here would have to be updated. https://sourceware.org/binutils/docs/as/File.html#File I'll have a look... (In reply to Nick Desaulniers from comment #0) > .file 0 "asdf" > .section .debug_info,"",@progbits > .long 3 > .short 5 > I *think* section "2.14 Declaration Coordinates" pdf page 68 of [0] > addresses this: > "The value 0 indicates that no source file has been specified." But doesn't that mean that your example assembler source is invalid, because it *is* providing a source file name ? Ie shouldn't the example be: .file 0 .section .debug_info,"",@progbits [...] The master branch has been updated by Nick Clifton <nickc@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=84d9ab33f3dc542c5f20abb9026240cfd48ccd97 commit 84d9ab33f3dc542c5f20abb9026240cfd48ccd97 Author: Nick Clifton <nickc@redhat.com> Date: Fri Mar 6 17:13:22 2020 +0000 Add support for a ".file 0" directive if supporting DWARF 5 or higher. PR 25614 * dwarf2dbg.c (dwarf2_directive_filename): Allow a file number of 0 if the dwarf_level is 5 or more. Complain if a filename follows a file 0. * testsuite/gas/elf/dwarf-5-file0.s: New test. * testsuite/gas/elf/dwarf-5-file0.d: New test driver. * testsuite/gas/elf/elf.exp: Run the new test. PR 25612 * config/tc-ia64.h (DWARF2_VERISION): Fix typo. * doc/as.texi: Fix another typo. I have applied a patch to support ".file 0", without a filename. I am not sure that it is doing the right thing however, in terms of line table generation. Do you have an example of some assembler source and the debug information that you would expect to be generated ? Created attachment 12356 [details]
foo.s
Attached what Clang produces for an empty function definition with -gdwarf-5. Hi Nick,
> Attached what Clang produces for an empty function definition with -gdwarf-5.
Please could you also upload the foo.o file that results from
assembling foo.s ?
Also - what does a file name for file 0 mean ?
Cheers
Nick
(In reply to Nick Clifton from comment #8) > Also - what does a file name for file 0 mean ? My reading of the DWARF v5 spec is that file 0 specifies the root source file (= the DW_AT_name from the compile-unit DIE). Similarly, directory 0 specifies the compilation directory (again copied from the compile-unit DIE). Why duplicate this information? So that an object can have all debug info *except* the line-table be stripped, and the line table still has all the relevant information. (At least, that was the justification given to the DWARF committee in favor of making this change.) HTH, --paulr Created attachment 12363 [details]
Assembled form of foo.s
Never mind - I have assembled it myself...
Hi Nick, Right - I have now checked in a patch which should provide full support for the ".file 0" directive. Plus it handles .file <N> "dir" "file" md5 <M> as well. One question - what is the .addrsig directive ? It is in the foo.s file that you uploaded (near the end) but gas does not recognise it. Also - please can you check to see if the patched assembler now provides the functionality that you need ? Cheers Nick (In reply to Nick Clifton from comment #11) > Hi Nick, > > Right - I have now checked in a patch which should provide full support for > the ".file 0" directive. Plus it handles .file <N> "dir" "file" md5 <M> as > well. > > One question - what is the .addrsig directive ? It is in the foo.s file > that you uploaded (near the end) but gas does not recognise it. Here's the documentation for the addrsig LLVM extension: https://llvm.org/docs/Extensions.html#sht-llvm-addrsig-section-address-significance-table (In reply to David Blaikie from comment #12) Hi David, > > One question - what is the .addrsig directive ? It is in the foo.s file > > that you uploaded (near the end) but gas does not recognise it. > > Here's the documentation for the addrsig LLVM extension: > https://llvm.org/docs/Extensions.html#sht-llvm-addrsig-section-address- > significance-table Thanks for the reference. This is obviously a new feature, so it will need a new PR being filed. Ideally of course someone from the LLVM community will offer a patch to add the feature, but if that does not happen then I will put it on my (long) list of things to do. Cheers Nick (In reply to Nick Clifton from comment #13) > (In reply to David Blaikie from comment #12) > Hi David, > > > > One question - what is the .addrsig directive ? It is in the foo.s file > > > that you uploaded (near the end) but gas does not recognise it. > > > > Here's the documentation for the addrsig LLVM extension: > > https://llvm.org/docs/Extensions.html#sht-llvm-addrsig-section-address- > > significance-table > > Thanks for the reference. This is obviously a new feature, so it will > need a new PR being filed. Ideally of course someone from the LLVM > community will offer a patch to add the feature, but if that does not > happen then I will put it on my (long) list of things to do. > > Cheers > Nick *nod* seems unlikely it'd be a high priority for participants either project, unless GCC folks find the feature itself to be valuable, want to implement it in gold/binutils ld, etc. Arguably LLVM/Clang could probably use a mode (& probably should be the default behavior for -fno-integrated-as, though overridable) that produces binutils as-compatible assembly & skip features like this. The master branch has been updated by Maciej W. Rozycki <macro@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=876678f05e70235ed71d5b9ec63e4f6db1ec76e4 commit 876678f05e70235ed71d5b9ec63e4f6db1ec76e4 Author: Maciej W. Rozycki <macro@linux-mips.org> Date: Tue Mar 31 23:01:36 2020 +0100 PR 25611, PR 25614: GAS: Remove a double inclusion of "bignum.h" Correct an issue with commit 5496f3c635dc ("Add support for generating DWARF-5 format directory and file name tables from the assembler.") and remove a duplicate direct inclusion of "bignum.h" from dwarf2dbg.c that causes a GAS compilation error: In file included from .../gas/dwarf2dbg.c:33: .../gas/bignum.h:42: error: redefinition of typedef 'LITTLENUM_TYPE' .../gas/bignum.h:42: error: previous declaration of 'LITTLENUM_TYPE' was here make[4]: *** [dwarf2dbg.o] Error 1 with some GCC versions, as this header has been already included via "as.h" and then "flonum.h". gas/ PR 25611 PR 25614 * dwarf2dbg.c: Do not include "bignum.h". (In reply to cvs-commit@gcc.gnu.org from comment #15) > The master branch has been updated by Maciej W. Rozycki > <macro@sourceware.org>: > > https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git; > h=876678f05e70235ed71d5b9ec63e4f6db1ec76e4 > > commit 876678f05e70235ed71d5b9ec63e4f6db1ec76e4 > Author: Maciej W. Rozycki <macro@linux-mips.org> > Date: Tue Mar 31 23:01:36 2020 +0100 > > PR 25611, PR 25614: GAS: Remove a double inclusion of "bignum.h" > > Correct an issue with commit 5496f3c635dc ("Add support for generating > DWARF-5 format directory and file name tables from the assembler.") and > remove a duplicate direct inclusion of "bignum.h" from dwarf2dbg.c that > causes a GAS compilation error: > > In file included from .../gas/dwarf2dbg.c:33: > .../gas/bignum.h:42: error: redefinition of typedef 'LITTLENUM_TYPE' > .../gas/bignum.h:42: error: previous declaration of 'LITTLENUM_TYPE' was > here > make[4]: *** [dwarf2dbg.o] Error 1 > > with some GCC versions, as this header has been already included via > "as.h" and then "flonum.h". > > gas/ > PR 25611 > PR 25614 > * dwarf2dbg.c: Do not include "bignum.h". bignum.h seems brittle - I guess there's a reason it doesn't have include guards? (if it doesn't have include guards, perhaps it shouldn't be included from other headers? Maybe given a different extension?) |