Bug 25614

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?)