Bug 25614

Summary: dwarf-5 allows for .file 0
Product: binutils Reporter: Nick Desaulniers <ndesaulniers>
Component: gasAssignee: 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
.file 0 "asdf"
.section .debug_info,"",@progbits
.long 3
.short 5

$ as x.s 
x.s: Assembler messages:
x.s:1: Error: file number less than one

It seems that dwarf-5 may have added support for `0` as a valid file number.  Clang warns:

$ clang x.s -c
x.s:1:1: warning: file 0 not supported prior to DWARF-5
.file 0 "asdf"
^
$ clang x.s -c -gdwarf-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."

See also [1].

[0] http://www.dwarfstd.org/doc/DWARF5.pdf
[1] https://bugs.llvm.org/show_bug.cgi?id=45040
Comment 1 Nick Desaulniers 2020-02-28 22:59:38 UTC
Also, documentation here would have to be updated. https://sourceware.org/binutils/docs/as/File.html#File
Comment 2 Nick Clifton 2020-03-03 13:40:00 UTC
I'll have a look...
Comment 3 Nick Clifton 2020-03-06 15:37:47 UTC
(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
  [...]
Comment 4 cvs-commit@gcc.gnu.org 2020-03-06 17:14:27 UTC
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.
Comment 5 Nick Clifton 2020-03-06 17:30:22 UTC
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 ?
Comment 6 Nick Desaulniers 2020-03-06 17:38:45 UTC
Created attachment 12356 [details]
foo.s
Comment 7 Nick Desaulniers 2020-03-06 17:39:21 UTC
Attached what Clang produces for an empty function definition with -gdwarf-5.
Comment 8 Nick Clifton 2020-03-09 13:09:53 UTC
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
Comment 9 Paul Robinson 2020-03-09 13:21:13 UTC
(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
Comment 10 Nick Clifton 2020-03-09 16:42:07 UTC
Created attachment 12363 [details]
Assembled form of foo.s

Never mind - I have assembled it myself...
Comment 11 Nick Clifton 2020-03-11 10:24:57 UTC
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
Comment 12 David Blaikie 2020-03-11 19:33:58 UTC
(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
Comment 13 Nick Clifton 2020-03-18 10:29:25 UTC
(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
Comment 14 David Blaikie 2020-03-18 20:12:22 UTC
(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.
Comment 15 cvs-commit@gcc.gnu.org 2020-03-31 22:03:04 UTC
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".
Comment 16 David Blaikie 2020-03-31 23:06:07 UTC
(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?)