[Bug gas/26740] New: Extra filename generated by --gdwarf-4

2020-10-15 Thread hjl.tools at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=26740

Bug ID: 26740
   Summary: Extra filename generated by --gdwarf-4
   Product: binutils
   Version: 2.36 (HEAD)
Status: NEW
  Severity: normal
  Priority: P2
 Component: gas
  Assignee: unassigned at sourceware dot org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

From

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97451

[hjl@gnu-skx-1 stage1-gcc]$ cat /tmp/x.s
.file   "lbasename.c"
.text
.p2align 4
.globl  unix_lbasename
.type   unix_lbasename, @function
unix_lbasename:
ret
.p2align 4
.globl  dos_lbasename
.type   dos_lbasename, @function
dos_lbasename:
.file 1 "/export/gnu/import/git/sources/gcc/libiberty/lbasename.c"
ret
.size   dos_lbasename, .-dos_lbasename
.file 2
"/export/gnu/import/git/sources/gcc/libiberty/../include/safe-ctype.h"
[hjl@gnu-skx-1 stage1-gcc]$ as --gdwarf-4 --64 -o x.o /tmp/x.s
[hjl@gnu-skx-1 stage1-gcc]$ readelf -w x.o | grep -A4 File
 The File Name Table (offset 0x87):
  Entry Dir TimeSizeName
  1 2   0   0   lbasename.c
  2 3   0   0   safe-ctype.h
  3 1   0   0   x.s <<< This shouldn't be there.
[hjl@gnu-skx-1 stage1-gcc]$

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug gas/26740] Extra filename generated by --gdwarf-4

2020-10-15 Thread hjl.tools at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=26740

H.J. Lu  changed:

   What|Removed |Added

 CC||mark at klomp dot org

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug gas/26740] Extra filename generated by --gdwarf-4

2020-10-15 Thread mark at klomp dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=26740

--- Comment #1 from Mark Wielaard  ---
The issue is that some instructions are emitted (dwarf2_emit_insn is called)
before the first .file  directive has been seen. This allocates x.s
(the input file) as first file entry. Later when the actual .file 1 lbasename.c
and .file 2 safe-ctype are seen the x.s entry is moved to entry 3. We don't
record that we never actually use that entry and so we still emit it.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug gas/26740] Extra filename generated by --gdwarf-4

2020-10-15 Thread hjl.tools at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=26740

H.J. Lu  changed:

   What|Removed |Added

   Target Milestone|--- |2.36

--- Comment #2 from H.J. Lu  ---
(In reply to Mark Wielaard from comment #1)
> The issue is that some instructions are emitted (dwarf2_emit_insn is called)
> before the first .file  directive has been seen. This allocates x.s
> (the input file) as first file entry. Later when the actual .file 1
> lbasename.c and .file 2 safe-ctype are seen the x.s entry is moved to entry
> 3. We don't record that we never actually use that entry and so we still
> emit it.

Is this a GCC bug? Even if it is, assembler shouldn't generate bad debug
info.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug gas/26740] Extra filename generated by --gdwarf-4

2020-10-15 Thread mark at klomp dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=26740

--- Comment #3 from Mark Wielaard  ---
(In reply to H.J. Lu from comment #2)
> (In reply to Mark Wielaard from comment #1)
> > The issue is that some instructions are emitted (dwarf2_emit_insn is called)
> > before the first .file  directive has been seen. This allocates x.s
> > (the input file) as first file entry. Later when the actual .file 1
> > lbasename.c and .file 2 safe-ctype are seen the x.s entry is moved to entry
> > 3. We don't record that we never actually use that entry and so we still
> > emit it.
> 
> Is this a GCC bug? Even if it is, assembler shouldn't generate bad debug
> info.

I don't think so. Although it might help if gcc emitted the .file 1 directive
earlier. The debug info isn't really bad, but it does contain an unused file
name which it really shouldn't. I am not yet sure how to fix that. 

In gas/dwarf2dbg.c you see that the file entry is moved when a .file NUM is
seen and the file entry is auto_assigned. I wonder if we should just replace it
instead of moving if dwarf2_any_loc_directive_seen is false (because then we
know it has never been used).

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug gas/26740] Extra filename generated by --gdwarf-4

2020-10-15 Thread mark at klomp dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=26740

Mark Wielaard  changed:

   What|Removed |Added

 CC||nickc at sourceware dot org

--- Comment #4 from Mark Wielaard  ---
Note that the auto_assigned moving of file entries was done because of PR25878.
Maybe Nick knows why the entries needed to be moved instead of simply being
reassigned.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug binutils/26741] New: benign use after free at bfd/elfxx-riscv.c:1403

2020-10-15 Thread msebor at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=26741

Bug ID: 26741
   Summary: benign use after free at bfd/elfxx-riscv.c:1403
   Product: binutils
   Version: 2.36 (HEAD)
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: msebor at gmail dot com
  Target Milestone: ---

Building Binutils with an experimental version of GCC triggers the following
warning due to the subset pointer being used after it has been freed.  The
pointer is indeterminate and using its value for any purpose (not just
dereferencing it) is undefined.

To avoid the warning, the two statements should be reversed.

/src/binutils-gdb/bfd/elfxx-riscv.c: In function ‘riscv_parse_subset’:
/src/binutils-gdb/bfd/elfxx-riscv.c:1403:27: warning: use after free
[-Wuse-after-free]
 1403 |   p += end_of_version - subset;
  |~~~^~~~
/src/binutils-gdb/bfd/elfxx-riscv.c:1402:7: note: freed by ‘free’ here
 1402 |   free (subset);
  |   ^

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug gas/26740] Extra filename generated by --gdwarf-4

2020-10-15 Thread hjl.tools at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=26740

H.J. Lu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #5 from H.J. Lu  ---
Dup.

*** This bug has been marked as a duplicate of bug 25878 ***

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug gas/25878] Error: file table slot 1 is already occupied by a different file

2020-10-15 Thread hjl.tools at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=25878

H.J. Lu  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #5 from H.J. Lu  ---
*** Bug 26740 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug gas/25878] Error: file table slot 1 is already occupied by a different file

2020-10-15 Thread hjl.tools at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=25878

H.J. Lu  changed:

   What|Removed |Added

 Resolution|FIXED   |---
 Status|RESOLVED|REOPENED

--- Comment #6 from H.J. Lu  ---
[hjl@gnu-cfl-2 pr26740]$ cat y.s 
.text
.global kretprobe_trampoline
kretprobe_trampoline:
ret
.file   0 "core.c" md5 0xbbd69fc03ce253b2dbaab2522dd519ae
.file   1 "types.h"
[hjl@gnu-cfl-2 pr26740]$ ./as --gdwarf-5  -o y.o y.s -32
[hjl@gnu-cfl-2 pr26740]$ readelf -wl y.o
Raw dump of debug contents of section .debug_line:

  Offset:  0x0
  Length:  118
  DWARF Version:   5
  Address size (bytes):4
  Segment selector (bytes):0
  Prologue Length: 97
  Minimum Instruction Length:  1
  Maximum Ops per Instruction: 1
  Initial value of 'is_stmt':  1
  Line Base:   -5
  Line Range:  14
  Opcode Base: 13

 Opcodes:
  Opcode 1 has 0 args
  Opcode 2 has 1 arg
  Opcode 3 has 1 arg
  Opcode 4 has 1 arg
  Opcode 5 has 1 arg
  Opcode 6 has 0 args
  Opcode 7 has 0 args
  Opcode 8 has 0 args
  Opcode 9 has 1 arg
  Opcode 10 has 0 args
  Opcode 11 has 0 args
  Opcode 12 has 1 arg

 The Directory Table (offset 0x22, lines 1, columns 1):
  Entry Name
  0 (indirect line string, offset: 0x0):
/export/home/hjl/bugs/binutils/pr26740

 The File Name Table (offset 0x2e, lines 3, columns 3):
  Entry Dir MD5 Name
  0 0 0xbbd69fc03ce253b2dbaab2522dd519ae(indirect line string, offset:
0x27): core.c
  1 0 0x(indirect line string, offset:
0x2e): types.h
  2 0 0x(indirect line string, offset:
0x36): y.s
^^ This shouldn't be here.

 Line Number Statements:
  [0x006d]  Extended opcode 2: set Address to 0x0
  [0x0074]  Special opcode 8: advance Address by 0 to 0x0 and Line by 3 to
4
  [0x0075]  Advance PC by 1 to 0x1
  [0x0077]  Extended opcode 1: End of Sequence


[hjl@gnu-cfl-2 pr26740]$

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug gas/25878] Error: file table slot 1 is already occupied by a different file

2020-10-15 Thread mark at klomp dot org
https://sourceware.org/bugzilla/show_bug.cgi?id=25878

Mark Wielaard  changed:

   What|Removed |Added

 CC||mark at klomp dot org

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug binutils/26741] benign use after free at bfd/elfxx-riscv.c:1403

2020-10-15 Thread amodra at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=26741

Alan Modra  changed:

   What|Removed |Added

   Last reconfirmed||2020-10-16
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Alan Modra  ---
> To avoid the warning, the two statements should be reversed.
Post your patch to binut...@sourceware.org and commit as obvious.

-- 
You are receiving this mail because:
You are on the CC list for the bug.