[Bug ld/15877] New: ld-gc/gc.exp FAIL with --gc-sections, pr14265

[vries at gcc dot gnu.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=15877

Bug ID: 15877
   Summary: ld-gc/gc.exp FAIL with --gc-sections, pr14265
   Product: binutils
   Version: 2.24 (HEAD)
Status: NEW
  Severity: minor
  Priority: P2
 Component: ld
  Assignee: unassigned at sourceware dot org
  Reporter: vries at gcc dot gnu.org

Similar to bug 14732, but for arm.

pr14265 fails for me when running with a gcc build with target
arm-linux-androideabi:
...
failed with: <>, expected: <>

failed with: <>, expected: <>
FAIL: --gc-sections with KEEP
...

Gcc build with target arm-linux-androideabi passes -fPIC by default. Adding
-fno-PIC to the cflags allows the test to pass.

Another way to reproduce the problem is to use an arm-linux-gnueabi gcc and add
-fPIC to the cflags.

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

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/15877] ld-gc/gc.exp FAIL with --gc-sections, pr14265

[vries at gcc dot gnu.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=15877

Tom de Vries  changed:

   What|Removed |Added

 Target||arm-linux-androideabi
 CC||vries at gcc dot gnu.org

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

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gold/16085] New: gold assumes STT_NOTYPE symbols are not thumb

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=16085

Bug ID: 16085
   Summary: gold assumes STT_NOTYPE symbols are not thumb
   Product: binutils
   Version: 2.25 (HEAD)
Status: NEW
  Severity: normal
  Priority: P2
 Component: gold
  Assignee: ian at airs dot com
  Reporter: vries at gcc dot gnu.org
CC: ccoutant at google dot com

Consider this test program (essentially function test_branch from
gdb/testsuite/gdb.arch/arm-disp-step.S, rewritten in C):
...
int
main (void)
{
  /* Gcc prints label 'L1' as '.L2' in assembler.  */
  asm goto ("b .L2; .global .L2;": : : : L1);
 L1:
  return 0;
}
...

We compile it:
...
$ arm-linux-androideabi-gcc test.c -static -mthumb -save-temps -O2
-march=armv7-a
...

Resulting in this test.s:
...
.syntax unified
.arch armv7-a
.fpu softvfp
.eabi_attribute 20, 1   @ Tag_ABI_FP_denormal
.eabi_attribute 21, 1   @ Tag_ABI_FP_exceptions
.eabi_attribute 23, 3   @ Tag_ABI_FP_number_model
.eabi_attribute 24, 1   @ Tag_ABI_align8_needed
.eabi_attribute 25, 1   @ Tag_ABI_align8_preserved
.eabi_attribute 26, 2   @ Tag_ABI_enum_size
.eabi_attribute 30, 2   @ Tag_ABI_optimization_goals
.eabi_attribute 34, 1   @ Tag_CPU_unaligned_access
.eabi_attribute 18, 4   @ Tag_ABI_PCS_wchar_t
.file   "test.c"
.section.text.startup,"ax",%progbits
.align  2
.global main
.thumb
.thumb_func
.type   main, %function
main:
b .L2
.global .L2
.thumb
.L2:
movsr0, #0  @,
bx  lr  @
.size   main, .-main
...


And this test.o:
...
SYMBOL TABLE:
 g F .text.startup  0008 main
0004 g   .text.startup   .L2

Disassembly of section .text.startup:

 :
   0:   f7ff bffe   b.w 4 <.L2>
0: R_ARM_THM_JUMP24 .L2

0004 <.L2>:
   4:   2000movsr0, #0
   6:   4770bx  lr
...

The first sign of trouble is here, in the dump of the executable:
...
80c8 :
80c8:   f00f b902   b.w 172d0 

80cc <.L2>:
80cc:   2000movsr0, #0
80ce:   4770bx  lr
...

The branch in main is not to .L2, but to here:
...
   172ce:   movsr0, r0
-->172d0:   4778bx  pc
   172d2:   46c0nop ; (mov r8, r8)
   172d4:   c37cstmia   r3!, {r2, r3, r4, r5, r6}
   172d6:   eaff 4778   ;  instruction: 0xeaff4778
... 
The 'bx pc; nop' is a trick to switch to arm mode, and the '.inst 0xeaffc37c'
following that is in fact a branch to .L2, but not shown as such because it's
disassembling in thumb mode.

Since we switch to arm mode, and then jump to thumb code at.L2, the execution
fails.

When doing the final link step using the bfd linker instead, we get:
...
80e8 :
80e8:   f000 b800   b.w 80ec <.L2>

80ec <.L2>:
80ec:   2000movsr0, #0
80ee:   4770bx  lr
...

The reason the gold linker introduces the stub, is because it thinks the target
of the jump is in arm mode. That is due to this code in
Target_arm::Relocate::relocate:
...
  else
{
  // Set thumb bit if symbol:
  // -Has type STT_ARM_TFUNC or
  // -Has type STT_FUNC, is defined and with LSB in value set.
  thumb_bit =
(((gsym->type() == elfcpp::STT_ARM_TFUNC)
 || (gsym->type() == elfcpp::STT_FUNC
 && !gsym->is_undefined()
 && ((psymval->value(object, 0) & 1) != 0)))
? 1
: 0);
}
...

The actual type of the symbol is STT_NOTYPE, and this code sets thumb_bit to 0
in such a case.

Knowing the cause of the failure, we can change the source to make the .L2
symbol of function type, which makes the problem go away:
...
  asm goto ("b .L2; .global .L2; .type   .L2, %%function": : : : L1);
...

Now, I'm not sure if the test-case is valid to begin with. But gold should
either:
- handle the STT_NO_TYPE (see in which function the target is, try to determine
thumbness of that function), or
- fail saying it cannot handle this relocation.

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

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gold/16085] gold assumes STT_NOTYPE symbols are not thumb

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=16085

--- Comment #1 from Tom de Vries  ---
- fail saying it cannot handle this relocation.

Which could look something like this:
...
Index: gold/arm.cc
===
--- gold/arm.cc (revision 422330)
+++ gold/arm.cc (working copy)
@@ -8865,6 +8865,9 @@ Target_arm::Relocate::reloca
   // If the final branch target of a relocation is THUMB instruction, this
   // is 1.  Otherwise it is 0.
   Arm_address thumb_bit = 0;
+  bool thumb_bit_valid = true;
   Symbol_value<32> symval;
   bool is_weakly_undefined_without_plt = false;
   bool have_got_offset = false;
@@ -8945,6 +8948,10 @@ Target_arm::Relocate::reloca
 && ((psymval->value(object, 0) & 1) != 0)))
? 1
: 0);
+
+ thumb_bit_valid = gsym->type() != elfcpp::STT_NOTYPE;
}
}
   else
@@ -9133,6 +9140,9 @@ Target_arm::Relocate::reloca
 case elfcpp::R_ARM_THM_CALL:
 case elfcpp::R_ARM_THM_XPC22:
 case elfcpp::R_ARM_THM_JUMP24:
+  gold_assert (thumb_bit_valid);
   reloc_status =
Arm_relocate_functions::thumb_branch_common(
r_type, relinfo, view, gsym, object, r_sym, psymval, address,
...

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

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gold/16085] gold assumes STT_NOTYPE symbols are not thumb

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=16085

Tom de Vries  changed:

   What|Removed |Added

 CC||vries at gcc dot gnu.org

--- Comment #2 from Tom de Vries  ---
FWIW, when using -Wl,--debug,all, I run into:
...
ld: internal error in thumb_branch_common, at gold/arm.cc:4101
...

which is this assert:
...
  if (stub_type != arm_stub_none)
{
  Stub_table* stub_table =
object->stub_table(relinfo->data_shndx);
  gold_assert(stub_table != NULL);
...

So printing debug info changes the trigger for an assert.

I've tracked the difference down to this code:
...
  // Return true if target wants to perform relaxation.
  bool
  may_relax() const
  {
// Run the dummy relaxation pass twice if relaxation debugging is enabled.
if (is_debugging_enabled(DEBUG_RELAXATION))
  return true;

 return this->do_may_relax();
  }

  // Perform a relaxation pass.  Return true if layout may be changed.
  bool
  relax(int pass, const Input_objects* input_objects, Symbol_table* symtab,
Layout* layout, const Task* task)
  {
// Run the dummy relaxation pass twice if relaxation debugging is enabled.
if (is_debugging_enabled(DEBUG_RELAXATION))
  return pass < 2;

return this->do_relax(pass, input_objects, symtab, layout, task);
  }
...

I'm a bit surprised that printing debug info by design changes the way the
program is run...

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

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gold/16085] gold assumes STT_NOTYPE symbols are not thumb

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=16085

--- Comment #3 from Tom de Vries  ---
Created attachment 7256
  --> https://sourceware.org/bugzilla/attachment.cgi?id=7256&action=edit
more complete version of the patch from comment 1

more complete version of the patch from comment 1

assert triggers when linking these files while running gdb testsuite:
...
gdb/testsuite/gdb.arch/arm-disp-step.S
gdb/testsuite/gdb.arch/thumb-singlestep.S
gdb/testsuite/gdb.asm/asmsrc[12].s
gdb/testsuite/gdb.dwarf2/dw2-cp-infcall-ref-static.S
gdb/testsuite/gdb.dwarf2/dw2-entry-value.S
gdb/testsuite/gdb.dwarf2/dw2-inline-param.S
gdb/testsuite/gdb.dwarf2/dw2-linkage-name-trust.S
gdb/testsuite/gdb.dwarf2/dw2-noloc.S
gdb/testsuite/gdb.dwarf2/dw2-param-error.S
gdb/testsuite/gdb.dwarf2/dw2-ref-missing-frame.S
gdb/testsuite/gdb.dwarf2/dw2-skip-prologue.S
gdb/testsuite/gdb.dwarf2/dw2-unresolved.S
gdb/testsuite/gdb.mi/dw2-ref-missing-frame.S
...

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

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug binutils/29319] New: [binutils] strip changes align of GNU_STACK segment

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=29319

Bug ID: 29319
   Summary: [binutils] strip changes align of GNU_STACK segment
   Product: binutils
   Version: 2.39 (HEAD)
Status: NEW
  Severity: normal
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

Created attachment 14194
  --> https://sourceware.org/bugzilla/attachment.cgi?id=14194&action=edit
gcore-relro-pie.gz

Consider the exec gcore-relro-pie (exec generated by the gdb testsuite), on
which we use strip:
...
$ strip -g -o gcore-relro-pie.stripped gcore-relro-pie
...

The align for the GNU_STACK segment drops from 16 to 8:
...
$ readelf -l -W gcore-relro-pie | egrep "GNU_STACK|Type"
  Type   Offset   VirtAddr   PhysAddr   FileSiz  MemSiz
  Flg Align
  GNU_STACK  0x00 0x 0x 0x00
0x00 RW  0x10
$ readelf -l -W gcore-relro-pie.stripped | egrep "GNU_STACK|Type"
  Type   Offset   VirtAddr   PhysAddr   FileSiz  MemSiz
  Flg Align
  GNU_STACK  0x00 0x 0x 0x00
0x00 RW  0x8
...

This mismatch causes gdb to classify gcore-relro-pie as unsuitable to combine
with a core file generated using gcore-relro-pie.stripped (PR29318).

Binutils needs to be build with --disable-separate-code in order to trigger
this.

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

[Bug binutils/29319] [binutils] strip changes align of GNU_STACK segment

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=29319

--- Comment #2 from Tom de Vries  ---
(In reply to H.J. Lu from comment #1)
> I can't reproduce it with
> 
> commit 736918239b16cc2ff57bfc64a982f2f0afc8c0f6
> Author: Xi Ruoyao 
> Date:   Tue Jul 5 19:30:12 2022 +0800
> 
> gdb: LoongArch: add orig_a0 into register set

Did you built with --disable-separate-code ?

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

[Bug binutils/29319] [binutils] strip changes align of GNU_STACK segment

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=29319

Tom de Vries  changed:

   What|Removed |Added

 Ever confirmed|1   |0
 Status|WAITING |UNCONFIRMED

--- Comment #3 from Tom de Vries  ---
(In reply to H.J. Lu from comment #1)
> I can't reproduce it with
> 
> commit 736918239b16cc2ff57bfc64a982f2f0afc8c0f6
> Author: Xi Ruoyao 
> Date:   Tue Jul 5 19:30:12 2022 +0800
> 
> gdb: LoongArch: add orig_a0 into register set

Build with that exact commit, and reproduced.

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

[Bug binutils/29319] [binutils] strip changes align of GNU_STACK segment

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=29319

--- Comment #5 from Tom de Vries  ---
(In reply to H.J. Lu from comment #4)
> Created attachment 14195 [details]
> A patch
> 
> Try this.

Fixes this for me, thanks.

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

[Bug binutils/29337] New: [readelf] CU/TU mixup in .gdb_index

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=29337

Bug ID: 29337
   Summary: [readelf] CU/TU mixup in .gdb_index
   Product: binutils
   Version: 2.39 (HEAD)
Status: NEW
  Severity: normal
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

Consider a hello.c (probably not relevant, just listing what I used):
...
$ cat hello.c
#include 

int
main (void)
{
  printf
("hello\n");
  return 0;
}
...

We compile with gcc 7.5.0, and add a .debug_types section:
...
$ gcc hello.c -g -fdebug-types-section
...

And we add a .debug_index section:
...
$ gdb-add-index a.out
...

Let's print the index entries for a type and a variable:

With 2.37:
...
$ ~/binutils/install/bin/readelf -wg a.out | egrep "_IO_FILE|stdout"
[718] _IO_FILE: T0 [static, type]
[823] stdout: 3 [global, variable]
...

Well, that looks all right.

We have 6 CUs and 1 TU:
...
CU table:
[  0] 0x0 - 0x2d
[  1] 0x2e - 0x6c
[  2] 0x6d - 0x8e
[  3] 0x8f - 0x184
[  4] 0x185 - 0x33c
[  5] 0x33d - 0x35e

TU table:
[  0] 0x0 0x1d f4c23649b49166b7 
...
and indeed the _IO_FILE type is part of the .debug_types section, which
contains a single type unit:
...
Contents of the .debug_types section:

  Compilation Unit @ offset 0x0:
   Length:0x22a (32-bit)
   Version:   4
   Abbrev Offset: 0x59
   Pointer Size:  8
   Signature: 0xf4c23649b49166b7
   Type Offset:   0x1d
 <0><17>: Abbrev Number: 1 (DW_TAG_type_unit)
<18>   DW_AT_language: 12   (ANSI C99)
<19>   DW_AT_stmt_list   : 0xe8
 <1><1d>: Abbrev Number: 2 (DW_TAG_structure_type)
<1e>   DW_AT_name: (indirect string, offset: 0x282): _IO_FILE
...
and the stdout variable is part of the CU at 0x8f:
...
  Compilation Unit @ offset 0x8f:
   Length:0xf2 (32-bit)
   Version:   4
   Abbrev Offset: 0x59
   Pointer Size:  8
 <0><9a>: Abbrev Number: 13 (DW_TAG_compile_unit)
 ...
 <1><120>: Abbrev Number: 16 (DW_TAG_variable)
<121>   DW_AT_name: (indirect string, offset: 0x40d): stdout
...
which is listed with index 3 in the CU table.

Let's try again, with 2.38:
...
$ ~/binutils/install/bin/readelf -wg a.out | egrep "_IO_FILE|stdout"
[718] _IO_FILE: T0 [static, type]
[823] stdout: 3 [global, variable]
...

Still looking good.

Not let's try with master:
...
$ ~/binutils/install/bin/readelf -wg a.out | egrep "_IO_FILE|stdout"
[718] _IO_FILE: T3 [static, type]
[823] stdout: T0 [global, variable]
...

Both T3 and T0 look wrong.

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

[Bug gas/29559] New: gas generated incorrect debug info (top-level DW_TAG_unspecified_type DIE)

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=29559

Bug ID: 29559
   Summary: gas generated incorrect debug info (top-level
DW_TAG_unspecified_type DIE)
   Product: binutils
   Version: unspecified
Status: NEW
  Severity: normal
  Priority: P2
 Component: gas
  Assignee: unassigned at sourceware dot org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

See the test-case in gdb PR29558.

Current trunk gas generates a top-level DIE with DW_TAG_unspecified_type:
...
  Compilation Unit @ offset 0xf4:
   Length:0x35 (32-bit)
   Version:   5
   Unit Type: DW_UT_compile (1)
   Abbrev Offset: 0xa3
   Pointer Size:  8
 <0><100>: Abbrev Number: 3 (DW_TAG_unspecified_type)
 <0><101>: Abbrev Number: 1 (DW_TAG_compile_unit)
<102>   DW_AT_stmt_list   : 0x123
<106>   DW_AT_low_pc  : 0x4004ac
<10e>   DW_AT_high_pc : 11
<10f>   DW_AT_name: test2.s
<113>   DW_AT_comp_dir: /home/vries/gdb_versions/devel
<117>   DW_AT_producer: GNU AS 2.39.50
<11b>   DW_AT_language: 32769   (MIPS assembler)
 <1><11d>: Abbrev Number: 2 (DW_TAG_subprogram)
<11e>   DW_AT_name: (indirect string, offset: 0x241): foo
<122>   DW_AT_external: 1
<122>   DW_AT_type: <0x100>
<123>   DW_AT_low_pc  : 0x4004ac
<12b>   DW_AT_high_pc : 11
...

This is incorrect dwarf, according to the standard (see PR29558 comment 3).

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

[Bug gas/29559] gas generated incorrect debug info (top-level DW_TAG_unspecified_type DIE)

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=29559

Tom de Vries  changed:

   What|Removed |Added

 CC||nickc at redhat dot com

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

[Bug gas/29559] gas generated incorrect debug info (top-level DW_TAG_unspecified_type DIE)

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=29559

--- Comment #2 from Tom de Vries  ---
(In reply to Nick Clifton from comment #1)
> Hi Tom,
> 
>   [For the record the patch that introduced this bug was intended to fix PR
> 29517].
> 
> >  <0><100>: Abbrev Number: 3 (DW_TAG_unspecified_type)
> >  <0><101>: Abbrev Number: 1 (DW_TAG_compile_unit)
>  
> OK, so you are saying that the DW_TAG_unspecified_type is in the wrong place
> ?
> 

Yes.

> Presumably it should be after DW_TAG_subprogram.  IE, something like this:
> 
>  <0><101>: Abbrev Number: 1 (DW_TAG_compile_unit)
> <102>   DW_AT_stmt_list   : 0x123
> <106>   DW_AT_low_pc  : 0x4004ac
> <10e>   DW_AT_high_pc : 11
> <10f>   DW_AT_name: test2.s
> <113>   DW_AT_comp_dir: /home/vries/gdb_versions/devel
> <117>   DW_AT_producer: GNU AS 2.39.50
> <11b>   DW_AT_language: 32769   (MIPS assembler)
>  <1><11d>: Abbrev Number: 2 (DW_TAG_subprogram)
> <11e>   DW_AT_name: (indirect string, offset: 0x241): foo
> <122>   DW_AT_external: 1
> <122>   DW_AT_type: <0x133>
> <123>   DW_AT_low_pc  : 0x4004ac
> <12b>   DW_AT_high_pc : 11
>  <1><133>: Abbrev Number: 3 (DW_TAG_unspecified_type)
> 
> I will try to fix this.  I originally placed the unspecified tag at the
> start of the CU information because I found that I could not otherwise
> compute the correct offset for it.  I will just have to try harder.

After the DW_TAG_compile_unit should also be fine.

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

[Bug gas/29559] gas generated incorrect debug info (top-level DW_TAG_unspecified_type DIE)

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=29559

--- Comment #3 from Tom de Vries  ---
Created attachment 14325
  --> https://sourceware.org/bugzilla/attachment.cgi?id=14325&action=edit
Dwarf assembly test-case


Currently, this fails:
...
(gdb) PASS: gdb.dwarf2/dw2-unspecified-type.exp: p ((int (*) ()) foo) ()
p (int) foo ()^M
Invalid cast.^M
(gdb) FAIL: gdb.dwarf2/dw2-unspecified-type.exp: p (int) foo ()
...
because DW_TAG_unspecified_type is translated as void.

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

[Bug gas/29559] gas generated incorrect debug info (top-level DW_TAG_unspecified_type DIE)

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=29559

Tom de Vries  changed:

   What|Removed |Added

  Attachment #14325|0   |1
is obsolete||

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

[Bug gas/29559] gas generated incorrect debug info (top-level DW_TAG_unspecified_type DIE)

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=29559

--- Comment #4 from Tom de Vries  ---
(In reply to Tom de Vries from comment #3)
> Created attachment 14325 [details]
> Dwarf assembly test-case
> 
> 
> Currently, this fails:
> ...
> (gdb) PASS: gdb.dwarf2/dw2-unspecified-type.exp: p ((int (*) ()) foo) ()
> p (int) foo ()^M
> Invalid cast.^M
> (gdb) FAIL: gdb.dwarf2/dw2-unspecified-type.exp: p (int) foo ()
> ...
> because DW_TAG_unspecified_type is translated as void.

Sorry, meant for the gdb PR.

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

[Bug gas/29559] gas generated incorrect debug info (top-level DW_TAG_unspecified_type DIE)

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=29559

--- Comment #7 from Tom de Vries  ---
Ack, FWIW, updated DWARF:
...
 <0><100>: Abbrev Number: 1 (DW_TAG_compile_unit)
<101>   DW_AT_stmt_list   : 0x123
<105>   DW_AT_low_pc  : 0x4004ac
<10d>   DW_AT_high_pc : 11
<10e>   DW_AT_name: (indirect string, offset: 0x22a): test2.s
<112>   DW_AT_comp_dir: (indirect string, offset: 0x1d1):
/home/vries/gdb_versions/dev
el
<116>   DW_AT_producer: (indirect string, offset: 0x232): GNU AS
2.39.50
<11a>   DW_AT_language: 32769   (MIPS assembler)
 <1><11c>: Abbrev Number: 2 (DW_TAG_subprogram)
<11d>   DW_AT_name: (indirect string, offset: 0x241): foo
<121>   DW_AT_external: 1
<121>   DW_AT_type: <0x12b>
<122>   DW_AT_low_pc  : 0x4004ac
<12a>   DW_AT_high_pc : 11
 <1><12b>: Abbrev Number: 3 (DW_TAG_unspecified_type)
 <1><12c>: Abbrev Number: 0
...

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

[Bug ld/29594] New: [ld, feature request] Add --ctf-functions

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=29594

Bug ID: 29594
   Summary: [ld, feature request] Add --ctf-functions
   Product: binutils
   Version: 2.40 (HEAD)
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: ld
  Assignee: unassigned at sourceware dot org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

Normally, when using gcc -gctf, gcc produces info for various things:
...
Contents of CTF section .ctf:

  Header:
Magic number: 0xdff2
Version: 4 (CTF_VERSION_3)
Flags: 0x2 (CTF_F_NEWFUNCINFO)
Compilation unit name: gdb/testsuite/gdb.base/ctf-constvars.c
Data object section:0x0 -- 0xcb (0xcc bytes)
Function info section:  0xcc -- 0xcf (0x4 bytes)
Object index section:   0xd0 -- 0x19b (0xcc bytes)
Function index section: 0x19c -- 0x19f (0x4 bytes)
Variable section:   0x1a0 -- 0x337 (0x198 bytes)
Type section:   0x338 -- 0x7ab (0x474 bytes)
String section: 0x7ac -- 0x9dc (0x231 bytes)
...
but after linking, both functions and variables are dropped:
...
  Header:
Magic number: 0xdff2
Version: 4 (CTF_VERSION_3)
Flags: 0xe (CTF_F_NEWFUNCINFO, CTF_F_IDXSORTED, CTF_F_DYNSTR)
Compilation unit name: gdb/testsuite/gdb.base/ctf-constvars.c
Type section:   0x0 -- 0x473 (0x474 bytes)
String section: 0x474 -- 0x51b (0xa8 bytes)
...

There's a linker flag: -Wl,--ctf-variables that makes ld pass variable info to
the exec, such that we have:
...
Contents of CTF section .ctf:

  Header:
Magic number: 0xdff2
Version: 4 (CTF_VERSION_3)
Flags: 0xe (CTF_F_NEWFUNCINFO, CTF_F_IDXSORTED, CTF_F_DYNSTR)
Compilation unit name: gdb/testsuite/gdb.base/ctf-constvars.c
Variable section:   0x0 -- 0x19f (0x1a0 bytes)
Type section:   0x1a0 -- 0x613 (0x474 bytes)
String section: 0x614 -- 0x844 (0x231 bytes)
...

But there's no equivalent for functions, so these still go missing.

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

[Bug gas/30064] New: gas generates v3 .debug_line contribution with -gdwarf-2

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30064

Bug ID: 30064
   Summary: gas generates v3 .debug_line contribution with
-gdwarf-2
   Product: binutils
   Version: unspecified
Status: NEW
  Severity: normal
  Priority: P2
 Component: gas
  Assignee: unassigned at sourceware dot org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

Consider the following test-case:
...
$ gcc-11 -g -gdwarf-2 ~/hello.c -gno-as-loc-support -c
$ readelf -wl hello.o | grep "DWARF Version"
  DWARF Version:   2
...

So we asked gcc to generate v2 dwarf, and it does.

Now let's try the same using .loc directives:
...
$ gcc-11 -g -gdwarf-2 ~/hello.c -gas-loc-support -c
$ readelf -wl hello.o | grep "DWARF Version"
  DWARF Version:   3
...

gcc-11 is new enough to pass -gdwarf-2 to gas, so that's not the problem.

Maybe we're using some extension that bumps the dwarf version to v3 (that seems
to be common practise in gas)?  Let's try again with -gstrict-dwarf:
...
$ gcc-11 -g -gstrict-dwarf -gdwarf-2 ~/hello.c -gas-loc-support -c
$ readelf -wl hello.o | grep "DWARF Version"
  DWARF Version:   3
...
Nope, still 3.

This is due to the fix for PR23941, which hardcodes the version of the
.debug_lines contribution to (minimally) v3.

Perhaps this is a wont-fix, but in that case IWBN if there was a comment here
stating that we ignore -gdwarf-2, and explaining why:
...
/* This implementation outputs version 3 .debug_line information.  */
#ifndef DWARF2_LINE_VERSION
#define DWARF2_LINE_VERSION (dwarf_level > 3 ? dwarf_level : 3)
#endif
...

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

[Bug gas/30064] gas generates v3 .debug_line contribution with -gdwarf-2

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30064

--- Comment #1 from Tom de Vries  ---
Submitted patch:
https://sourceware.org/pipermail/binutils/2023-January/125868.html

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

[Bug gas/30064] gas generates v3 .debug_line contribution with -gdwarf-2

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30064

--- Comment #2 from Tom de Vries  ---
For the record, problem noticed here (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108600#c3 ).

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

[Bug binutils/30758] New: ODR violations in opcodes dir

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30758

Bug ID: 30758
   Summary: ODR violations in opcodes dir
   Product: binutils
   Version: unspecified
Status: NEW
  Severity: normal
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

I'm filing this duplicate of gdb PR30757, to raise awareness of an ODR
violation problem related to the opcodes dir.

Sofar I haven't been able to reproduce with any component other than gdb.

But the opcodes dir is maintained by the binutils maintainers, hence this PR
(with the unfortunate binutils component, I guess something like "other" would
be appropriate at this point).

Perhaps the binutils maintainers know how to reproduce this outside of gdb.

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

[Bug binutils/30758] ODR violations in opcodes dir

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30758

--- Comment #2 from Tom de Vries  ---
(In reply to Nick Clifton from comment #1)
> Hi Tom,
> 
>   How are you configuring and building the sources when you encounter 
>   this error ?
> 

Like so:
...
$ cat build.sh
#!/bin/sh

pwd=$(pwd -P)

src=$pwd/../src

build=$pwd/build
rm -Rf $build
mkdir $build

cd $build

$src/configure \
CFLAGS="-flto -O2 -g -Wall" \
CXXFLAGS="-flto -O2 -g -Wall" \
--enable-targets=all \
--disable-sim \
2>&1 \
| tee CONFIGURELOG

cd $build/gdb

make \
all-gdb \
2>&1 \
| tee MAKELOG
...

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

[Bug binutils/30758] ODR violations in opcodes dir

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30758

--- Comment #4 from Tom de Vries  ---
Created attachment 15070
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15070&action=edit
MAKELOG.gz

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

[Bug binutils/30758] ODR violations in opcodes dir

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30758

--- Comment #3 from Tom de Vries  ---
Created attachment 15069
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15069&action=edit
CONFIGURELOG.gz

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

[Bug binutils/30758] ODR violations in opcodes dir

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30758

Tom de Vries  changed:

   What|Removed |Added

 Blocks|22395   |
   Severity|normal  |enhancement

--- Comment #6 from Tom de Vries  ---
(In reply to Alan Modra from comment #5)
> I'm guessing that it is the use of opcodes cgen headers in gdb itself that
> is triggering these warnings, not the use of those headers in opcodes.  I
> think I'd be looking at gdb/mep-tdep.c and gdb/or1k-tdep.c, perhaps trying
> to replace use of cgen types in structs defined there by void*.  Does it
> even make sense for g++ to complain about odr violations in extern "C"
> headers?

Thanks for the suggestion.

I went looking in this direction, and came across this doc (
https://en.cppreference.com/w/cpp/language/definition ) where it's suggested to
use unnamed namespaces to work around odr problems with types.

And indeed, this patch fixes the warnings:
...
diff --git a/gdb/mep-tdep.c b/gdb/mep-tdep.c
index fc786f09e44..8de2c588bad 100644
--- a/gdb/mep-tdep.c
+++ b/gdb/mep-tdep.c
@@ -48,8 +48,10 @@

 /* Get the user's customized MeP coprocessor register names from
libopcodes.  */
+namespace {
 #include "opcodes/mep-desc.h"
 #include "opcodes/mep-opc.h"
+}



 /* The gdbarch_tdep structure.  */
diff --git a/gdb/or1k-tdep.h b/gdb/or1k-tdep.h
index a11950584d7..b6ec91ab38e 100644
--- a/gdb/or1k-tdep.h
+++ b/gdb/or1k-tdep.h
@@ -23,8 +23,10 @@
 #define TARGET_OR1K
 #endif

+namespace {
 #include "opcodes/or1k-desc.h"
 #include "opcodes/or1k-opc.h"
+}

 /* General Purpose Registers */
 #define OR1K_ZERO_REGNUM  0
...

That's a fix on the gdb side.  So I guess this PR on the opcodes side is about
making that patch unnecessary, which would AFAIU involve generating uniquely
named types in cgen.

Of course, this PR could be closed as resolved-wontfix or some such if that's
deemed not a good idea or unnecessary.


Referenced Bugs:

https://sourceware.org/bugzilla/show_bug.cgi?id=22395
[Bug 22395] ODR violations
-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug binutils/30758] ODR violations in opcodes dir

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30758

--- Comment #7 from Tom de Vries  ---
(In reply to Tom de Vries from comment #6)
> ...
> diff --git a/gdb/mep-tdep.c b/gdb/mep-tdep.c
> index fc786f09e44..8de2c588bad 100644
> --- a/gdb/mep-tdep.c
> +++ b/gdb/mep-tdep.c
> @@ -48,8 +48,10 @@
>  
>  /* Get the user's customized MeP coprocessor register names from
> libopcodes.  */
> +namespace {
>  #include "opcodes/mep-desc.h"
>  #include "opcodes/mep-opc.h"
> +}
>  
>  
> 
>  /* The gdbarch_tdep structure.  */
> diff --git a/gdb/or1k-tdep.h b/gdb/or1k-tdep.h
> index a11950584d7..b6ec91ab38e 100644
> --- a/gdb/or1k-tdep.h
> +++ b/gdb/or1k-tdep.h
> @@ -23,8 +23,10 @@
>  #define TARGET_OR1K
>  #endif
>  
> +namespace {
>  #include "opcodes/or1k-desc.h"
>  #include "opcodes/or1k-opc.h"
> +}
>  
>  /* General Purpose Registers */
>  #define OR1K_ZERO_REGNUM  0
> ...

Hmm, that build ok with gcc 7.5.0, but when trying again with gcc 12.3.0, I
get:
...
opcodes/mep-opc.h:59: warning: type of 'mep_config_map' does not match original
declaration [-Wlto-type-mismatch]
   59 | extern mep_config_map_struct mep_config_map[];
  |
opcodes/mep-opc.h:57: note: type 'struct mep_config_map_struct' defined in
anonymous namespace cannot match type 'struct mep_config_map_struct' across the
translation unit boundary
   57 | } mep_config_map_struct;
  |
opcodes/mep-opc.c:92: note: the incompatible type defined in another
translation unit
   92 | mep_config_map_struct mep_config_map[] =
  |
opcodes/mep-opc.c:92: note: 'mep_config_map' was previously declared here
opcodes/mep-opc.c:92: note: code may be misoptimized unless
'-fno-strict-aliasing' is used
...

Now also mep-opc.c is involved.

I'm not sure if the warning makes sense, but I imagine doing the unnamed
namespace trick in the opcodes headers alongside the extern "C" stuff would fix
this.

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

[Bug binutils/30758] ODR violations in opcodes dir

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30758

--- Comment #8 from Tom de Vries  ---
(In reply to Tom de Vries from comment #7)
> I'm not sure if the warning makes sense, but I imagine doing the unnamed
> namespace trick in the opcodes headers alongside the extern "C" stuff would
> fix this.

It doesn't, and besides that it's an anti-pattern (
https://rules.sonarsource.com/cpp/RSPEC-1000/ ).

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

[Bug binutils/30758] ODR violations in opcodes dir

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30758

--- Comment #9 from Tom de Vries  ---
(In reply to Tom de Vries from comment #7)
> Hmm, that build ok with gcc 7.5.0, but when trying again with gcc 12.3.0, I
> get:

Same with gcc 13.1.1.

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

[Bug binutils/30758] ODR violations in opcodes dir

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30758

--- Comment #10 from Tom de Vries  ---
I've submitted a workaround for gdb, using this approach:
...
 #define cgen_operand_type _cgen_operand_type
 #define cgen_hw_type  _cgen_hw_type
 #include "opcodes/-desc.h"
...

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

[Bug binutils/30835] New: [readelf] Incorrect warning with .gnu_debugaltlink (.debug_info offset in .debug_aranges section does not point to a CU header)

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30835

Bug ID: 30835
   Summary: [readelf] Incorrect warning with .gnu_debugaltlink
(.debug_info offset in .debug_aranges section does not
point to a CU header)
   Product: binutils
   Version: 2.42 (HEAD)
Status: NEW
  Severity: normal
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

I was using readelf to look at the executables in the gdb testcase
gdb.dwarf2/dwzbuildid.exp, and ran into a warning:
...
$ ~/binutils/install/bin/readelf -w
./leap-15-4/build/gdb/testsuite/outputs/gdb.dwarf2/dwzbuildid/dwzbuildid-ok >
READELF
readelf: Warning: .debug_info offset of 0x2e in .debug_aranges section does not
point to a CU header.
...

The .debug_aranges section where the warning originates is shown here:
...
Contents of the .debug_aranges section (loaded from
/data/vries/gdb/leap-15-4/build/gdb/testsuite/outputs/gdb.dwarf2/dwzbuildid/dwzbuildid3.o):

  Length:   28
  Version:  2
  Offset into .debug_info:  0
  Pointer Size: 8
  Segment Size: 0

AddressLength
 
  Length:   28
  Version:  2
  Offset into .debug_info:  0x2e
  Pointer Size: 8
  Segment Size: 0

AddressLength
 
...
and the corresponding .debug_info section is:
...
Contents of the .debug_info section (loaded from
/data/vries/gdb/leap-15-4/build/gdb/testsuite/outputs/gdb.dwarf2/dwzbuildid/dwzbuildid3.o):

  Compilation Unit @ offset 0:
   Length:0x7 (32-bit)
   Version:   4
   Abbrev Offset: 0
   Pointer Size:  8
  Compilation Unit @ offset 0xb:
   Length:0x1f (32-bit)
   Version:   4
   Abbrev Offset: 0x1
   Pointer Size:  8
 <0><16>: Abbrev Number: 2 (DW_TAG_compile_unit)
<17>   DW_AT_language: 2(non-ANSI C)
 <1><18>: Abbrev Number: 3 (DW_TAG_base_type)
<19>   DW_AT_name: int
<1d>   DW_AT_byte_size   : 4
<1e>   DW_AT_encoding: 5(signed)
 <1><1f>: Abbrev Number: 4 (DW_TAG_constant)
<20>   DW_AT_name: the_int
<28>   DW_AT_type: <0x18>
<2c>   DW_AT_const_value : 99
 <1><2d>: Abbrev Number: 0
  Compilation Unit @ offset 0x2e:
   Length:0x7 (32-bit)
   Version:   4
   Abbrev Offset: 0x1f
   Pointer Size:  8
...

There seems to be a CU at 0x2e, so the warning looks incorrect.

When using readelf directly on the .gnu_debugaltlink file (dwzbuildid3.o), the
warning is not there.

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

[Bug gas/31115] [ARM] The minimalistic DWARF DIE for function has wrong address in Thumb mode

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31115

Tom de Vries  changed:

   What|Removed |Added

 CC||vries at gcc dot gnu.org

--- Comment #6 from Tom de Vries  ---
Filed gdb counterpart PR tdep/31453.

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

[Bug binutils/31605] New: [readelf, -wL] Highlight empty address range

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31605

Bug ID: 31605
   Summary: [readelf, -wL] Highlight empty address range
   Product: binutils
   Version: unspecified
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

Consider gdb test-case gdb.dwarf2/dw2-epilogue-begin.exp.

With readelf -wL , we have:
...
File nameLine numberStarting addressViewStmt

dw2-epilogue-begin.c  440x4101e8   x
dw2-epilogue-begin.c  470x4101ec   x
dw2-epilogue-begin.c   -0x4101ec
...

The entry for line 47 has an empty address range (and consequently gdb ignores
it), but it's not obvious from the readelf output.

I wonder if making this clear somehow using an annotation would be a good idea.

Say:
...
File nameLine numberStarting addressViewStmt

dw2-epilogue-begin.c  440x4101e8   x
dw2-epilogue-begin.c  47   ~0x4101ec   x
dw2-epilogue-begin.c   -0x4101ec
...

Or displaying the address in parentheses.

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

[Bug binutils/31609] New: [readelf, -wL] Stmt column misaligned with -W

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31609

Bug ID: 31609
   Summary: [readelf, -wL] Stmt column misaligned with -W
   Product: binutils
   Version: unspecified
Status: NEW
  Severity: normal
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

Consider gdb test-case gdb.dwarf2/dw2-epilogue-begin.exp.

With readelf -W -wL , we have:
...
CU: /data/vries/gdb/src/gdb/testsuite/gdb.dwarf2/dw2-epilogue-begin.c:
File nameLine numberStarting addressView   
Stmt

/data/vries/gdb/src/gdb/testsuite/gdb.dwarf2/dw2-epilogue-begin.c:
dw2-epilogue-begin.c  200x4004b7  
x
dw2-epilogue-begin.c  270x4004be  
x
dw2-epilogue-begin.c  340x4004d0  
x
dw2-epilogue-begin.c  370x4004de  
x
dw2-epilogue-begin.c  380x4004ec  
x
dw2-epilogue-begin.c  430x4004ef  
x
dw2-epilogue-begin.c  470x4004fa  
x
dw2-epilogue-begin.c  500x4004ff  
x
dw2-epilogue-begin.c   -0x40050d
...

The Stmt column (the x-es) is one char before its headers first letter.

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

[Bug binutils/31722] New: [binutils/readelf] Missing eol in warning string index of converts to an offset of which is too big for section

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31722

Bug ID: 31722
   Summary: [binutils/readelf] Missing eol in warning string index
of  converts to an offset of  which is too big
for section 
   Product: binutils
   Version: 2.43 (HEAD)
Status: NEW
  Severity: normal
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

With a proposed gdb test-case and target board fission, I run into:
...
$ readelf -w outputs/gdb.base/check-errno/check-errno-macros > READELF
readelf: Warning: string index of 624 converts to an offset of 0x9c8 which is
too big for section .debug_str.dworeadelf: Warning: string index of 625
converts to an offset of 0x9cc which is too big for section .debug_str.dwo$
...

With this fix:
...
diff --git a/binutils/dwarf.c b/binutils/dwarf.c
index 3ce79f4e5d1..d9131cf473d 100644
--- a/binutils/dwarf.c
+++ b/binutils/dwarf.c
@@ -669,7 +669,7 @@ fetch_indexed_string (uint64_t idx,
   || index_offset + offset_size > index_section->size)
 {
   warn (_("string index of %" PRIu64 " converts to an offset of %#" PRIx64
- " which is too big for section %s"),
+ " which is too big for section %s\n"),
idx, index_offset, str_section->name);

   return _("");
...
we get instead:
...
$ readelf -w outputs/gdb.base/check-errno/check-errno-macros > READELF
readelf: Warning: string index of 624 converts to an offset of 0x9c8 which is
too big for section .debug_str.dwo
readelf: Warning: string index of 625 converts to an offset of 0x9cc which is
too big for section .debug_str.dwo
$
...

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

[Bug binutils/31722] [binutils/readelf] Missing eol in warning string index of converts to an offset of which is too big for section

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31722

--- Comment #3 from Tom de Vries  ---
(In reply to Nick Clifton from comment #2)
> Hi Tom,
> 
>   Thanks for pointing this out.  It turns out there are quite a few
>   warning messages in that source file that are missing a terminating
>   \n character so I have gone ahead and extended your patch to cover
>   them all.  (I hope ... I must admit I only performed a visual scan
>   of the code.  I did not a sophisticated grep of some kind).
> 
> Cheers
>   Nick

Hi Nick,

thanks for fixing this.

Cheers,
- Tom

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

[Bug binutils/31734] New: [binutils, readelf] dwarf4 .debug_str_offsets section printed incorrectly

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31734

Bug ID: 31734
   Summary: [binutils, readelf] dwarf4 .debug_str_offsets section
printed incorrectly
   Product: binutils
   Version: 2.43 (HEAD)
Status: NEW
  Severity: normal
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

Consider a hello world, compiled with split dwarf:
...
$ gcc-13 -gdwarf-4 -gsplit-dwarf -ggnu-pubnames -fdebug-types-section
-Wl,--gdb-index -fuse-ld=gold ~/data/hello.c -g3 -save-temps -dA
...

When dumping dwarf with readelf we get:
...
$ readelf -w a.out > READELF
readelf: Warning: string index of 707 converts to an offset of 0xb14 which is
too big for section .debug_str.dwo
readelf: Warning: string index of 708 converts to an offset of 0xb18 which is
too big for section .debug_str.dwo
...

If we look into the a-hello.s, the first three entries are:
...
.section.debug_str_offsets.dwo,"e",@progbits
.long   0   # indexed string 0x0: __FLT16_NORM_MAX__
6.5504000e+4F16
.long   0x3f# indexed string 0x1: _SIZE_T_
.long   0x49# indexed string 0x2: __SIG_ATOMIC_MAX__ 0x7fff
...
but readelf starts here, at the third entry:
...
Contents of the .debug_str_offsets.dwo section (loaded from
/home/vries/gdb/a-hello.dwo):

Length: 0xb14
   Index   Offset [String]
   0   __SIG_ATOMIC_MAX__ 0x7fff
...

llvm-dwarfdump starts at the first entry, and doesn't warn or error out.

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

[Bug binutils/31734] [binutils, readelf] dwarf4 .debug_str_offsets section printed incorrectly

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31734

--- Comment #1 from Tom de Vries  ---
Fixed by:
...
diff --git a/binutils/dwarf.c b/binutils/dwarf.c
index c5ccc50dae7..8125c64e1b6 100644
--- a/binutils/dwarf.c
+++ b/binutils/dwarf.c
@@ -7969,6 +7969,7 @@ display_debug_str_offsets (struct dwarf_section *section,
  length = section->size;
  curr   = section->start;
  entries_end = end;
+ debug_str_offsets_hdr_len = 0;

  printf (_("Length: %#" PRIx64 "\n"), length);
  printf (_("   Index   Offset [String]\n"));
...
with which we get:
...
Contents of the .debug_str_offsets.dwo section (loaded from
/home/vries/gdb/a-hello.dwo):

Length: 0xb14
   Index   Offset [String]
   0   __FLT16_NORM_MAX__
6.5504000e+4F16
   1 003f  _SIZE_T_
   2 0049  __SIG_ATOMIC_MAX__ 0x7fff
...

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

[Bug binutils/31734] [binutils, readelf] dwarf4 .debug_str_offsets section printed incorrectly

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31734

--- Comment #2 from Tom de Vries  ---
My guess is that this is a regression since:
...
commit 407115429b349a55561213a61e910756c965f902
Author: Bhuvanendra Kumar N 
Date:   Mon Jul 4 16:20:29 2022 +0530

Modified changes for split-dwarf and dwarf-5.
...

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

[Bug binutils/31735] New: [binutils, readelf] debug_str_offsets used, should use debug_str_offsets.dwo

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31735

Bug ID: 31735
   Summary: [binutils, readelf] debug_str_offsets used, should use
debug_str_offsets.dwo
   Product: binutils
   Version: 2.43 (HEAD)
Status: NEW
  Severity: normal
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

[ Using gcc trunk, and the tentative patch for this (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115066 ) PR. ]

This compilation now generates sane dwarf:
...
$ gcc -gdwarf-4 -gsplit-dwarf /data/vries/hello.c -g3 -save-temps -dA
...

But with readelf -w a.out, we get:
...
Contents of the .debug_macro.dwo section (loaded from
/home/vries/gcc/a-hello.dwo):

  Offset:  0
  Version: 4
  Offset size: 4
  Offset into .debug_line: 0

 DW_MACRO_start_file - lineno: 0 filenum: 1
 DW_MACRO_define_strx lineno : 0 macro : 
 DW_MACRO_define_strx lineno : 0 macro : 
 DW_MACRO_define_strx lineno : 0 macro : 
...

Fixed by:
...
diff --git a/binutils/dwarf.c b/binutils/dwarf.c
index c5ccc50dae7..ae3a9d68a5b 100644
--- a/binutils/dwarf.c
+++ b/binutils/dwarf.c
@@ -6504,7 +6504,7 @@ display_debug_macro (struct dwarf_section *section
,
  READ_ULEB (lineno, curr, end);
  READ_ULEB (offset, curr, end);
  string = (const unsigned char *)
-   fetch_indexed_string (offset, NULL, offset_size, false, 0);
+   fetch_indexed_string (offset, NULL, offset_size, is_dwo, 0);

  if (op == DW_MACRO_define_strx)
printf (" DW_MACRO_define_strx ");
  else
...
after which we get:
...
Contents of the .debug_macro.dwo section (loaded from
/home/vries/gcc/a-hello.dwo):

  Offset:  0
  Version: 4
  Offset size: 4
  Offset into .debug_line: 0

 DW_MACRO_start_file - lineno: 0 filenum: 1
 DW_MACRO_define_strx lineno : 0 macro : __STDC__ 1
 DW_MACRO_define_strx lineno : 0 macro : __STDC_VERSION__ 201710L
 DW_MACRO_define_strx lineno : 0 macro : __STDC_UTF_16__ 1
...

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

[Bug binutils/31735] [binutils, readelf] debug_str_offsets used, should use debug_str_offsets.dwo

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31735

--- Comment #1 from Tom de Vries  ---
Created attachment 15518
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15518&action=edit
a.out.gz

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

[Bug binutils/31735] [binutils, readelf] debug_str_offsets used, should use debug_str_offsets.dwo

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31735

--- Comment #2 from Tom de Vries  ---
Created attachment 15519
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15519&action=edit
a-hello.dwo.gz

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

[Bug binutils/31735] [binutils, readelf] debug_str_offsets used, should use debug_str_offsets.dwo

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31735

--- Comment #4 from Tom de Vries  ---
(In reply to Alan Modra from comment #3)
> Please apply your fix.

Thanks for the review.

I've also added a test-case, which made me realize I needed an additional fix
for readelf -wm (instead of readelf -w).

Submitted here: https://sourceware.org/pipermail/binutils/2024-May/134049.html

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

[Bug binutils/31734] [binutils, readelf] dwarf4 .debug_str_offsets section printed incorrectly

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31734

--- Comment #4 from Tom de Vries  ---
(In reply to Alan Modra from comment #3)
> (In reply to Tom de Vries from comment #1)
> Please apply.

Thanks for the review.

Submitted with test-case here (
https://sourceware.org/pipermail/binutils/2024-May/134050.html ).

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

[Bug binutils/31734] [binutils, readelf] dwarf4 .debug_str_offsets section printed incorrectly

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31734

Tom de Vries  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Target Milestone|--- |2.43
 Status|NEW |RESOLVED

--- Comment #6 from Tom de Vries  ---
Fixed.

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

[Bug binutils/31735] [binutils, readelf] debug_str_offsets used, should use debug_str_offsets.dwo

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31735

Tom de Vries  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
   Target Milestone|--- |2.43
 Resolution|--- |FIXED

--- Comment #6 from Tom de Vries  ---
Fixed.

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

[Bug libctf/32044] New: [libctf, build] ctf-spec.texi:809: warning: @xref should not appear on @multitable line

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=32044

Bug ID: 32044
   Summary: [libctf, build] ctf-spec.texi:809: warning: @xref
should not appear on @multitable line
   Product: binutils
   Version: 2.44 (HEAD)
Status: NEW
  Severity: normal
  Priority: P2
 Component: libctf
  Assignee: unassigned at sourceware dot org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

Warning triggered during gdb build.

The line is:
...
@multitable {Kind} {@code{CTF_K_VOLATILE}} {Indicates a type that cannot be
represented in CTF, or that} {@xref{Pointers typedefs and cvr-quals}}
...

The table seems to have three columns:
...
@headitem Kind @tab Macro @tab Purpose
...
so the @xref corresponding to a fourth column seems superfluous.

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

[Bug gas/23423] New: generic directive to mark data as insn

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=23423

Bug ID: 23423
   Summary: generic directive to mark data as insn
   Product: binutils
   Version: 2.32 (HEAD)
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: gas
  Assignee: unassigned at sourceware dot org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

[ Follow up to discussion at
https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01542.html ]

Pre-9 gcc generates this tls sequence for fPIC on x86_64:
...
0x00 .byte 0x66
0x01 leaq  x@tlsgd(%rip),%rdi
0x08 .word 0x
0x0a rex64
0x0b call __tls_get_addr@plt
...

When compiling with -g, a .loc before the tls sequence is associated with the
first insn in the tls sequence, which is the leaq, so it points inside the
sequence rather than to the start of the sequence. Then, when ld relaxes the
sequence, the .loc may end up pointing inside an insn (maybe we want at least a
warning from ld there?). This will cause an executable containing such a
misplaced .loc to crash when gdb continues from the associated breakpoint.

This problem has been fixed in gcc 9 in an architecture-specific way: by using
arch-specific prefix data16 instead of .byte 0x66.

It would be nice if we could somehow have a generic way in gas to indicate
start (and maybe end) of insn when using  .byte/.value/.long/.quad to construct
insns.

F.i.:
...
.insn
.byte 0x66
.endinsn
...

Or this, which allows us to express that the .byte is a
prefix to an existing insn:
...
.insn
.byte 0x66
leaq  x@tlsgd(%rip),%rdi
.endinsn
...

For mips, there's an architecture-specific .insn directive already:
https://sourceware.org/binutils/docs/as/MIPS-insn.html#MIPS-insn .

For some other archs, f.i. arm there's a .inst directive (
https://sourceware.org/binutils/docs/as/ARM-Directives.html#ARM-Directives )
which allows operands to be specified, but I'm not sure how much that makes
sense for a generic directive.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gold/24250] New: [gold] Section offsets not monotonically increasing with --gdb-index

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=24250

Bug ID: 24250
   Summary: [gold] Section offsets not monotonically increasing
with --gdb-index
   Product: binutils
   Version: 2.33 (HEAD)
Status: NEW
  Severity: normal
  Priority: P2
 Component: gold
  Assignee: ccoutant at gmail dot com
  Reporter: vries at gcc dot gnu.org
CC: ian at airs dot com
  Target Milestone: ---

[ Filed earlier as dwz PR24249 - "Section offsets not monotonically
increasing". ]

When using the gold linker to generate the .gdb_index section:
...
$ gcc hello.c -g -fuse-ld=gold -Wl,--gdb-index
...

and inspecting the section offsets around .gdb_index:
...
$ readelf -S a.out | grep '[[]' | egrep -C1  'Offset|\.gdb_index'
  [Nr] Name  Type Address   Offset
  [ 0]   NULL   
--
  [31] .debug_strPROGBITS   1b2f
  [32] .gdb_indexPROGBITS   34b0
  [33] .debug_ranges PROGBITS   21f0
...
we see that the offsets are not monotonically increasing.

The property that the file offsets of the entries in the section header table
are in a monotonically increasing order, is not a requirement of the ELF
standard, but it is expected by a variety of other tools which process ELF
binaries.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug binutils/21191] objcopy --only-keep-debug creates non-monotonically increasing section offsets

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=21191

Tom de Vries  changed:

   What|Removed |Added

 CC||vries at gcc dot gnu.org

--- Comment #3 from Tom de Vries  ---
(In reply to Richard Biener from comment #2)
> (In reply to Alan Modra from comment #1)
> > What tool was complaining about sh_offset?  Fix it please.
> 
> It is DWZ complaining,

Filed as dwz PR24251 - "Allocatable section after non-allocatable ones"

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug binutils/24809] objcopy to not add SECTION symbols if section .note.gnu.gold-version present

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=24809

Tom de Vries  changed:

   What|Removed |Added

  Component|tools   |binutils
Version|unspecified |2.33 (HEAD)
Product|elfutils|binutils
Summary|eu-unstrip to drop SECTION  |objcopy to not add SECTION
   |symbols if section  |symbols if section
   |.note.gnu.gold-version  |.note.gnu.gold-version
   |present |present

--- Comment #2 from Tom de Vries  ---
(In reply to Mark Wielaard from comment #1)
> I can replicate this if I use objcopy to produce the hello.debug and
> hello.stripped binaries. But why don't you just use eu-strip?
> 

I think the idea here is to have the tools from the two "products" to play nice
together.

> Doing:
> $ eu-strip -f hello.debug -o hello.stripped hello
> $ eu-unstrip hello.stripped hello.debug -o hello.unstripped
> 
> Produces:
> $ ls -la
> -rwxrwxr-x. 1 mark mark 10416 Jul 15 14:50 hello
> -rw-rw-r--. 1 mark mark92 Jul 15 14:50 hello.c
> -rwxrwxr-x. 1 mark mark  6840 Jul 15 14:52 hello.debug
> -rwxrwxr-x. 1 mark mark  6488 Jul 15 14:52 hello.stripped
> -rwxrwxr-x. 1 mark mark 10416 Jul 15 14:52 hello.unstripped
> 
> $ readelf -s hello.debug | grep -c SECTION
> 0
> $ readelf -s hello.stripped | grep -c SECTION
> 0
> $ readelf -s hello.unstripped | grep -c SECTION
> 0
> 
> Which seems much more reasonable than what objcopy does.
> 

Right, I noticed that.

> I am not sure eu-unstrip should remove extra stuff objcopy adds. It seems
> that if the user created these bigger than necessary .debug and .stripped
> files, then they wanted that for some reason. It seems unwise to second
> guess the user.
> 
> If there is a bug, then I think it is simply a bug in objcopy, which can be
> prevented by using eu-strip instead.

OK, changing product to binutils.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug binutils/24809] objcopy to not add SECTION symbols if section .note.gnu.gold-version present

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=24809

--- Comment #5 from Tom de Vries  ---
(In reply to Nick Clifton from comment #4)
> (In reply to cvs-com...@gcc.gnu.org from comment #3)
> > The master branch has been updated by Nick Clifton :
> > 
> > https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;
> > h=48467cb99b04c9d908ce2dd74422c9c3f322ccc3
>  
> Sorry - this is not a patch for this PR.  It was a patch submitted by a
> different person called Tom, and I got confused.  Doh!

Ah I see, thanks for mentioning this.  I was confused there for a bit.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gold/26039] New: gold doesn't add PIE flag

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26039

Bug ID: 26039
   Summary: gold doesn't add PIE flag
   Product: binutils
   Version: unspecified
Status: NEW
  Severity: normal
  Priority: P2
 Component: gold
  Assignee: ccoutant at gmail dot com
  Reporter: vries at gcc dot gnu.org
CC: ian at airs dot com
  Target Milestone: ---

[ Spinoff of PR26031. ]

A PIE flag is added by ld to the dynamic flags when generating a
position-independent executable:
...
$ gcc hello.c -fPIE -pie
$ readelf -d a.out | grep FLAGS
 0x6ffb (FLAGS_1)Flags: PIE
$
...

But not by gold:
...
$ gcc hello.c -fPIE -pie -fuse-ld=gold
$ readelf -d a.out | grep FLAGS
$
...

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

[Bug gas/26143] New: gas generates invalid line table entry

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26143

Bug ID: 26143
   Summary: gas generates invalid line table entry
   Product: binutils
   Version: 2.35 (HEAD)
Status: NEW
  Severity: normal
  Priority: P2
 Component: gas
  Assignee: unassigned at sourceware dot org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

Consider test.c:
...
#include 

int
foo (int a)
{
  int w = a;

  if (a < 0)
w = -(unsigned int) a;

  if (w < 0)
abort ();

   return w;
}
...

Compiled like this:
...
gcc-9 test.c -O2 -g -c -save-temps -fno-reorder-blocks-and-partition -v
...

resulting in test.s:
...
.file   "test.c"
.text
.Ltext0:
.p2align 4
.globl  foo
.type   foo, @function
foo:
.LVL0:
.LFB13:
.file 1 "test.c"
.loc 1 5 1 view -0
.cfi_startproc
.loc 1 6 3 view .LVU1
.loc 1 8 3 view .LVU2
.loc 1 5 1 is_stmt 0 view .LVU3
movl%edi, %eax
.loc 1 8 6 view .LVU4
testl   %edi, %edi
js  .L7
.LVL1:
.L2:
.loc 1 14 4 is_stmt 1 view .LVU5
.loc 1 15 1 is_stmt 0 view .LVU6
ret
.LVL2:
.p2align 4,,10
.p2align 3
.L7:
.loc 1 9 5 is_stmt 1 view .LVU7
.loc 1 9 9 is_stmt 0 view .LVU8
negl%eax
.LVL3:
.loc 1 11 3 is_stmt 1 view .LVU9
.loc 1 11 6 is_stmt 0 view .LVU10
testl   %eax, %eax
jns .L2
.loc 1 12 5 is_stmt 1 view .LVU11
.LVL4:
.loc 1 5 1 is_stmt 0 view .LVU12
pushq   %rax
.cfi_def_cfa_offset 16
.loc 1 12 5 view .LVU13
callabort
.LVL5:
.loc 1 12 5 view .LVU14
.cfi_endproc
.LFE13:
.size   foo, .-foo
.Letext0:
...

resulting in the following line-table (readelf -wL):
...
CU: ./test.c:
File name   Line numberStarting addressViewStmt
test.c  5   0   x
test.c  6   0   1   x
test.c  8   0   2   x
test.c  5   0   3
test.c  8 0x2
test.c 14 0x6   x
test.c 15 0x6   1
test.c  90x10   x
test.c  90x10   1
test.c 110x12   x
test.c 110x12   1
test.c 120x16   x
test.c  50x16   1
test.c 120x17
test.c 120x1c
test.c 120x1c   1
...

or the last three entries in encoded form (readelf -wl):
...
  [0x007f]  Special opcode 26: advance Address by 1 to 0x17 and Line by 7
to 12
  [0x0080]  Special opcode 75: advance Address by 5 to 0x1c and Line by 0
to 12
  [0x0081]  Extended opcode 1: End of Sequence
...

According to the dwarf standard:
...
Every line number program sequence must end with a DW_LNE_end_sequence
instruction which creates a row whose address is that of the byte after the
last target machine instruction of the sequence.
...

Furthermore, for special opcodes we have:
...
Each ubyte special opcode has the following effect on the state machine:
1. Add a signed integer to the line register.
2. Modify the operation pointer by incrementing the address and op_index
   registers
3. Append a row to the matrix using the current values of the state machine
   registers.
...

So, we have a contradiction here.

One the one hand, the end-of-sequence declares that address 0x1c is one past
the byte of the last target machine instruction of the sequence.

On the other hand, the special opcode declares a target instruction starting at
address 0x1c, that is part of that same sequence.

This is due to the .loc before the .cfi_endproc, and specifically, due to the
view bit.  If we drop the view bit, the .loc is ignored.

The view bit is documented as:
...
view value

This option causes a row to be added to .debug_line in reference to the
current address (which might not be the same as that of the following assembly
instruction), and to associate value with the view register in the .debug_line
state machine. If value is a label, both the view register and the label are
set to the number of prior .loc directives at the same program location. If
value is the literal 0, the view register is set to zero, and the assembler
asserts that there aren’t any prior .loc directives at the same program
location. If value is the literal -0, the assembler arrange for the view
register to be reset in this row, even if there are prior .loc directives at
the same program location.
...

I cannot tell from the formulation "in reference to the current address (which
might not be the same as that of the following assembly instruction)" whether
this particular instance of .loc usage i

[Bug gas/26143] gas generates invalid line table entry

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26143

Tom de Vries  changed:

   What|Removed |Added

 CC||aoliva at sourceware dot org

--- Comment #2 from Tom de Vries  ---
(In reply to Nick Clifton from comment #1)
> (In reply to Tom de Vries from comment #0)
> Hi Tom,
> 
> >   [0x0080]  Special opcode 75: advance Address by 5 to 0x1c and Line by
> > 0 to 12
> >   [0x0081]  Extended opcode 1: End of Sequence
> 
> > Every line number program sequence must end with a DW_LNE_end_sequence
> > instruction which creates a row whose address is that of the byte after the
> > last target machine instruction of the sequence.
> 
> > One the one hand, the end-of-sequence declares that address 0x1c is one past
> > the byte of the last target machine instruction of the sequence.
> > 
> > On the other hand, the special opcode declares a target instruction starting
> > at address 0x1c, that is part of that same sequence.
> 
> Ah - but special opcodes do not necessarily assert that there is a target
> instruction starting at the address they reference.  

Hi Nick,

As indicated in dwarf4 standard 6.2.5.1 point 3, each special opcode adds a row
to the matrix.

Each row represents a machine instruction, as implied here in 6.2:
...
If space were not a consideration, the information provided in the .debug_line
section could be represented as a large matrix, with one row for each
instruction in the emitted object code.
...
The exception is a row with end_sequence set to true, but that's not the case
for the row generated by:
...
  [0x0080]  Special opcode 75: advance Address by 5 to 0x1c and Line by 0
to 12
...

So, I don't agree with this assessment.

If you still think my interpretation is wrong, you should state an alternative
one.  What does the generated row mean according to you, in terms of the DWARF
standard?

> 
> 
> > This option causes a row to be added to .debug_line in reference to the
> > current address (which might not be the same as that of the following
> > assembly instruction),  
> 
> > I cannot tell from the formulation "in reference to the current address
> > (which might not be the same as that of the following assembly instruction)"
> > whether this particular instance of .loc usage is valid.
> 
> My take on this is that the "view" directive specifies a property for an
> address, but it does not require that there be an instruction at that
> address.  Hence the generated line number table is correct...
> 

I'm not sure the semantics of the view directive are relevant to the
correctness of the generated line number table.

It's my understanding that the implementation for views intends to emit pure
dwarf with no extensions, and that the view info can be interpreted by
consumers with support, and ignored by consumers without support.

After watching Alexandre Oliva's 2017 GNU Cauldron presentation, I get the
impression that the "which might not be the same as that of the following
assembly instruction" formulation refers to a situation like this:
...
.loc
.balign 32 
.loc
  insn1
...
where the first loc may or may not refer to insn1.

...

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

[Bug binutils/26829] New: [readelf] wrong dir printed for .dwo file listing

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26829

Bug ID: 26829
   Summary: [readelf] wrong dir printed for .dwo file listing
   Product: binutils
   Version: unspecified
Status: NEW
  Severity: normal
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

Consider the source files gdb/testsuite/gdb.dwarf2/fission-multi-cu*.c,
compiled like this:
...
$ clang -g -gsplit-dwarf -flto *.c
...

Using readelf on the a.out to look at the generated dwarf, we get:
...
$ ~/binutils/install/bin/readelf -w a.out 2>&1 | more
The .debug_info section contains link(s) to dwo file(s):

  Name:  a.out_dwo/0.dwo
  Directory: /home/abuild/rpmbuild/BUILD/glibc-2.26/csu
  ID:d9 0e 49 4a b8 f0 7b f3

readelf: Warning: Unable to load dwo file:
/home/abuild/rpmbuild/BUILD/glibc-2.26/csu/a.out_dw
o/0.dwo
  Name:  a.out_dwo/0.dwo
  Directory: /home/vries/fission/fission-multi-cu
  ID:04 88 5d 18 be ef c8 0b

a.out: Found separate debug object file:
/home/vries/fission/fission-multi-cu/a.out_dwo/0.dwo
...

It seems the wrong directory was used for the first ID.

That is, the dir of one of the other CUs was used:
...
$ grep DW_AT_comp_dir.*: READELF | sed 's/:.*:/:/'
<24>   DW_AT_comp_dir: /home/abuild/rpmbuild/BUILD/glibc-2.26/csu
<43>   DW_AT_comp_dir: /home/abuild/rpmbuild/BUILD/glibc-2.26/csu
   DW_AT_comp_dir: /home/abuild/rpmbuild/BUILD/glibc-2.26/csu
   DW_AT_comp_dir: /home/vries/fission/fission-multi-cu
<107>   DW_AT_comp_dir: /home/vries/fission/fission-multi-cu
<13c>   DW_AT_comp_dir: /home/abuild/rpmbuild/BUILD/glibc-2.26/csu
<2f7>   DW_AT_comp_dir: /home/abuild/rpmbuild/BUILD/glibc-2.26/csu
...

The skeleton CUs look fine though, with the correct DW_AT_comp_dir:
...
 <0>: Abbrev Number: 1 (DW_TAG_compile_unit)
   DW_AT_stmt_list   : 0xe9
   DW_AT_comp_dir: /home/vries/fission/fission-multi-cu
   DW_AT_GNU_pubnames: 1
   DW_AT_GNU_dwo_name: a.out_dwo/0.dwo
   DW_AT_GNU_dwo_id  : 0xbc8efbe185d8804
   DW_AT_low_pc  : 0x4004a0
   DW_AT_high_pc : 0xf
   DW_AT_GNU_addr_base: 0x0
 <0><102>: Abbrev Number: 1 (DW_TAG_compile_unit)
<103>   DW_AT_stmt_list   : 0x13c
<107>   DW_AT_comp_dir: /home/vries/fission/fission-multi-cu
<10b>   DW_AT_GNU_pubnames: 1
<10b>   DW_AT_GNU_dwo_name: a.out_dwo/0.dwo
<10f>   DW_AT_GNU_dwo_id  : 0xf37bf0b84a490ed9
<117>   DW_AT_low_pc  : 0x4004b0
<11f>   DW_AT_high_pc : 0x14
<123>   DW_AT_GNU_addr_base: 0x0
...

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

[Bug binutils/26829] [readelf] wrong dir printed for .dwo file listing

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26829

--- Comment #1 from Tom de Vries  ---
Created attachment 12940
  --> https://sourceware.org/bugzilla/attachment.cgi?id=12940&action=edit
tgz file containing a.out and 0.dwo

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

[Bug binutils/26841] New: objcopy --extract-dwo silently drops relocation

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26841

Bug ID: 26841
   Summary: objcopy --extract-dwo silently drops relocation
   Product: binutils
   Version: unspecified
Status: NEW
  Severity: normal
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

This is a binutils PR corresponding to gcc PR "[gsplit-dwarf] label generated
for .debug_abbrev.dwo offset, corresponding relocation ignored by objcopy
--extract-dwo" at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97713.

The question is what to do with relocations relative to .dwo sections.

Currently these are silently ignored by objcopy --extract-dwo.

Either:
- there should be a warning that the relocation is ignored, or
- the relocation should be implemented.

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

[Bug binutils/26841] objcopy --extract-dwo silently drops relocation

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26841

--- Comment #2 from Tom de Vries  ---
(In reply to Nick Clifton from comment #1)
> Created attachment 12944 [details]
> Proposed patch
> 
> Hi Tom,
> 
>   It seems to me that we ought to keep the relocations.
> 
>   So please could you try out this patch and let me know if it works for you.
> 

I've tried this out.  It works in the sense that:
- readelf a-hello.dwo now correctly reads the the dwarf
- gdb a.out manages to read the info, and do a successful "ptype main"
However, lldb already hangs when doing "b main".

I'm not sure if this is the best solution.

It's trivial to resolve these relocations once at objcopy time, so why pass
them on to be resolved at load/run-time more than once?  That looks
unnecessary, and it requires readers to handle this correctly (which,
apparently lldb doesn't).

Furthermore, mentioning dwarf 5 standard bit @ "7.3.2.2 Second Partition
(Unlinked or in a .dwo File)":
...
Split DWARF object files do not get linked with any other files, therefore
references between sections must not make use of normal object file relocation
information. As a result, symbolic references within or between sections are
not
possible.
...

So, AFAIU it's already questionable that labels are allowed in a dwo section in
the first place.  If we assume that they're not allowed, we can still allow
labels in the pre-split dwo section to make things easier to emit for the
compiler, but after objcopy --extract-dwo the labels should be resolved into
constants.

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

[Bug binutils/26841] objcopy --extract-dwo silently drops relocation

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26841

--- Comment #3 from Tom de Vries  ---
(In reply to Tom de Vries from comment #2)

> So, AFAIU it's already questionable that labels are allowed in a dwo section
> in the first place.  If we assume that they're not allowed, we can still
> allow labels in the pre-split dwo section to make things easier to emit for
> the compiler, but after objcopy --extract-dwo the labels should be resolved
> into constants.

Alternatively, we could choose not to make things easier for the compiler, and
error out when encountering a .rela.*.dwo section.

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

[Bug binutils/26841] objcopy --extract-dwo silently drops relocation

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26841

--- Comment #5 from Tom de Vries  ---
(In reply to Nick Clifton from comment #4)
> Created attachment 12945 [details]
> Proposed patch
> 
> Hi Tom,
> 
> > Alternatively, we could choose not to make things easier for the compiler, 
> > and 
> > error out when encountering a .rela.*.dwo section.
> 
> Well if the spec says that they are not allowed then that does make things
> easier.
> 
> How about this revised patch ?  It makes the assembler issue an error
> message if the user tries to assemble a file containing DWO sections that
> need relocations, and it makes objcopy complain if it is asked to extract
> the dwo sections of a file which has relocations against those sections.
> 

I've asked for feedback on the GCC side.

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

[Bug ld/26936] New: [ld, PIE] ld drops relocation for .text.__x86.get_pc_thunk.bx

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26936

Bug ID: 26936
   Summary: [ld, PIE] ld drops relocation for
.text.__x86.get_pc_thunk.bx
   Product: binutils
   Version: 2.35
Status: NEW
  Severity: normal
  Priority: P2
 Component: ld
  Assignee: unassigned at sourceware dot org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

[ This is the ld variant of gdb PR26935. ]

Consider gcc testsuite test-case src/gcc/testsuite/gcc.dg/split-1.c.

When specifying -fsplit-stack, morestack.o is linked in, originating from
morestack.S in libgcc.

When specifying -m32 in combination with -fsplit-stack, morestack.o also
contains a function __x86.get_pc_thunk.bx, in section
.text.__x86.get_pc_thunk.bx.

So, when compiling like this:
...
$ gcc -g -fsplit-stack src/gcc/testsuite/gcc.dg/split-1.c -m32
...
we get in .debug_lines:
...
CU: libgcc/config/i386/morestack.S:
File nameLine number   Starting addressViewStmt
morestack.S  109   0x8048a1e   x
morestack.S  113   0x8048a1f   x
  ...
morestack.S  832   0x8048b80   x
morestack.S  838   0x8048b85   x
morestack.S-   0x8048b86

morestack.S  636   0x8048880   x
morestack.S  637   0x8048883   x
morestack.S-   0x8048884
...
corresponding to:
...
08048a1e <__morestack_non_split>:
 8048a1e:   50  push   %eax
...
and:
...
08048880 <__x86.get_pc_thunk.bx>:
 8048880:   8b 1c 24mov(%esp),%ebx
...

Now, we compile in addition with -pie -fPIE, and get instead in .debug_lines:
...
CU: libgcc/config/i386/morestack.S:
File nameLine number   Starting addressViewStmt
morestack.S  109   0xb8b   x
morestack.S  113   0xb8c   x
   ...
morestack.S  838   0xcf2   x
morestack.S-   0xcf3

morestack.S  636   0   x
morestack.S  637 0x3   x
morestack.S- 0x4
...
which matches with:
...
0b8b <__morestack_non_split>:
 b8b:   50  push   %eax
...
but not with:
...
0b87 <__x86.get_pc_thunk.ax>:
 b87:   8b 04 24mov(%esp),%eax
...

Looking at the relocations for .debug_line in morestack.o, we have:
...
Relocation section '.rel.debug_line' at offset 0x8f4 contains 2 entries:
 Offset InfoTypeSym. Value  Symbol's Name
004e  0101 R_386_32      .text
00de  0501 R_386_32     
.text.__x86.get_pc_thunk.bx
...
matching with .debug_lines here:
...
 Line Number Statements:
  [0x004b]  Extended opcode 2: set Address to 0x0
...
and:
...
  [0x00db]  Extended opcode 2: set Address to 0x0
...

So, it looks like ld drops the second relocation in PIE mode.

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

[Bug ld/26936] [ld, PIE] ld drops relocation for .text.__x86.get_pc_thunk.bx

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26936

--- Comment #1 from Tom de Vries  ---
Gold variant filed at PR26937.

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

[Bug gold/26937] New: [gold, PIE] ld drops relocations for .text.__x86.get_pc_thunk.bx

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26937

Bug ID: 26937
   Summary: [gold, PIE] ld drops relocations for
.text.__x86.get_pc_thunk.bx
   Product: binutils
   Version: 2.35
Status: NEW
  Severity: normal
  Priority: P2
 Component: gold
  Assignee: ccoutant at gmail dot com
  Reporter: vries at gcc dot gnu.org
CC: ian at airs dot com
  Target Milestone: ---

[ This is the gold variant of gdb PR26935 and ld PR26936. ] 

Basically, with gold we have the same problems as ld, described in PR26936.

But for gold, the same problem occur also for .debug_ranges and .debug_aranges.

In .debug_ranges, we can observe that the second range starts at zero:
...
0028   (base address)
0028 0bbb 0d23
0028  0004
0028 
...

While in morestack.o we have:
...
Relocation section '.rel.debug_ranges' at offset 0x914 contains 4 entries:
 Offset InfoTypeSym. Value  Symbol's Name
0008  0101 R_386_32      .text
000c  0101 R_386_32      .text
0010  0401 R_386_32     
.text.__x86.get_pc_thunk.bx
0014  0401 R_386_32     
.text.__x86.get_pc_thunk.bx
...
and:
...
Contents of the .debug_ranges section:

Offset   BeginEnd
   (base address)
  0168 
  0004 
 
...

Likewise for .debug_aranges.

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

[Bug ld/26936] [ld, PIE] ld drops relocation for .text.__x86.get_pc_thunk.bx

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26936

--- Comment #3 from Tom de Vries  ---
Created attachment 12995
  --> https://sourceware.org/bugzilla/attachment.cgi?id=12995&action=edit
split-1.s

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

[Bug ld/26936] [ld, PIE] ld drops relocation for .text.__x86.get_pc_thunk.bx

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26936

--- Comment #4 from Tom de Vries  ---
Created attachment 12996
  --> https://sourceware.org/bugzilla/attachment.cgi?id=12996&action=edit
morestack.S

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

[Bug ld/26936] [ld, PIE] ld drops relocation for .text.__x86.get_pc_thunk.bx

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26936

Tom de Vries  changed:

   What|Removed |Added

 Ever confirmed|1   |0
 Status|WAITING |UNCONFIRMED

--- Comment #5 from Tom de Vries  ---
Reproduces like this:
...
$ gcc -g split-1.s morestack.S -m32 -pie 
$ readelf -wL a.out | grep morestack.S | tail
morestack.S  808   0xcde   x
morestack.S  812   0xce4   x
morestack.S  830   0xce5   x
morestack.S  831   0xce9   x
morestack.S  832   0xced   x
morestack.S  838   0xcf2   x
morestack.S-   0xcf3
morestack.S  636   0   x
morestack.S  637 0x3   x
morestack.S- 0x4
...

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

[Bug ld/26936] [ld, PIE] ld drops relocation for .text.__x86.get_pc_thunk.bx

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26936

--- Comment #6 from Tom de Vries  ---
(In reply to Tom de Vries from comment #0)
> So, when compiling like this:
> ...
> $ gcc -g -fsplit-stack src/gcc/testsuite/gcc.dg/split-1.c -m32
> ...

It's not clear to me from comment 2, have you tried this?

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

[Bug ld/26936] [ld, PIE] ld drops relocation for .text.__x86.get_pc_thunk.bx

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26936

--- Comment #8 from Tom de Vries  ---
(In reply to H.J. Lu from comment #7)
> (In reply to Tom de Vries from comment #6)
> > (In reply to Tom de Vries from comment #0)
> > > So, when compiling like this:
> > > ...
> > > $ gcc -g -fsplit-stack src/gcc/testsuite/gcc.dg/split-1.c -m32
> > > ...
> > 
> > It's not clear to me from comment 2, have you tried this?
> 
> I got
> 
> [hjl@gnu-cfl-2 tmp]$ file a.out 
> a.out: ELF 32-bit LSB pie executable, Intel 80386, version 1 (SYSV),
> dynamically linked, interpreter /lib/ld-linux.so.2,
> BuildID[sha1]=59ea9d8ac326aacb2ceb44abae5ad442d00e047c, for GNU/Linux 3.2.0,
> with debug_info, not stripped
> [hjl@gnu-cfl-2 tmp]$ gdb a.out 
> GNU gdb (GDB) Fedora 10.1-2.0.fc33
> Copyright (C) 2020 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> Type "show copying" and "show warranty" for details.
> This GDB was configured as "x86_64-redhat-linux-gnu".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> .
> Find the GDB manual and other documentation resources online at:
> .
> 
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from a.out...
> (gdb) b  __x86.get_pc_thunk.bx
> Breakpoint 1 at 0x11b0: file morestack.S, line 636.
> (gdb) r
> Starting program: /tmp/a.out 
> Missing separate debuginfos, use: dnf debuginfo-install
> glibc-2.32-2.0.fc33.i686
> 
> Breakpoint 1, __x86.get_pc_thunk.bx () at morestack.S:636
> Missing separate debuginfos, use: dnf debuginfo-install
> libgcc-10.2.1-6.1.fc33.i686
> (gdb) 
> 
> Does it look OK?

I see, yes that looks OK, thanks for showing me.

I hope then that it will reproduce for you with the .s based approach from
comments 3/4/5.

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

[Bug ld/26936] [ld, PIE] ld drops relocation for .text.__x86.get_pc_thunk.bx

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26936

Tom de Vries  changed:

   What|Removed |Added

 Ever confirmed|1   |0
Version|2.35|2.36 (HEAD)
 Status|WAITING |UNCONFIRMED

--- Comment #10 from Tom de Vries  ---
(In reply to H.J. Lu from comment #9)
> (In reply to Tom de Vries from comment #8)
> 
> > 
> > I see, yes that looks OK, thanks for showing me.
> > 
> > I hope then that it will reproduce for you with the .s based approach from
> > comments 3/4/5.
> 
> Please try binutils master branch.

Build binutils from today's commit 50757f95a8:
...
$ ls ~/binutils/install/bin/
addr2line  c++filt  ld  nm   objdump  readelf  strings
ar elfedit  ld.bfd  objcopy  ranlib   size strip
...

So we have:
...
$ ~/binutils/install/bin/ld -v
GNU ld (GNU Binutils) 2.35.50.20201124
...

Then build the .s files using the freshly build ld:
...
$ gcc -B /home/vries/binutils/install/bin -g split-1.s morestack.S -m32 -pie
-Wl,-v
collect2 version 7.5.0
/home/vries/binutils/install/bin/ld -plugin
/usr/lib64/gcc/x86_64-suse-linux/7/liblto_plugin.so
-plugin-opt=/usr/lib64/gcc/x86_64-suse-linux/7/lto-wrapper
-plugin-opt=-fresolution=/tmp/ccAPzqvf.res -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --build-id
--eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -pie
/usr/lib64/gcc/x86_64-suse-linux/7/../../../../lib/Scrt1.o
/usr/lib64/gcc/x86_64-suse-linux/7/../../../../lib/crti.o
/usr/lib64/gcc/x86_64-suse-linux/7/32/crtbeginS.o
-L/usr/lib64/gcc/x86_64-suse-linux/7/32
-L/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/lib/../lib
-L/usr/lib64/gcc/x86_64-suse-linux/7/../../../../lib -L/lib/../lib
-L/usr/lib/../lib -L/home/vries/binutils/install/bin
-L/usr/lib64/gcc/x86_64-suse-linux/7
-L/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/lib
-L/usr/lib64/gcc/x86_64-suse-linux/7/../../.. /tmp/ccvuPjjl.o /tmp/ccwj6r5B.o
-v -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s
--no-as-needed /usr/lib64/gcc/x86_64-suse-linux/7/32/crtendS.o
/usr/lib64/gcc/x86_64-suse-linux/7/../../../../lib/crtn.o
GNU ld (GNU Binutils) 2.35.50.20201124
...

And, reproduced:
...
$ ~/binutils/install/bin/readelf -wL a.out | grep morestack.S | tail
morestack.S  808  0x151e   x
morestack.S  812  0x1524   x
morestack.S  830  0x1525   x
morestack.S  831  0x1529   x
morestack.S  832  0x152d   x
morestack.S  838  0x1532   x
morestack.S-  0x1533
morestack.S  636   0   x
morestack.S  637 0x3   x
morestack.S- 0x4
...

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

[Bug ld/26936] [ld, PIE] ld drops relocation for .text.__x86.get_pc_thunk.bx

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26936

--- Comment #11 from Tom de Vries  ---
(In reply to Tom de Vries from comment #10)
> And, reproduced:

To put it in gdb terms:
...
$ gdb -q a.out
Reading symbols from a.out...
(gdb) b  __x86.get_pc_thunk.bx
Breakpoint 1 at 0x11d0: file ../sysdeps/i386/crti.S, line 66.
(gdb) r
Starting program: a.out 
Missing separate debuginfos, use: zypper install
glibc-32bit-debuginfo-2.26-lp152.26.3.1.x86_64

Breakpoint 1, __x86.get_pc_thunk.bx () at ../sysdeps/i386/crti.S:66
66  ../sysdeps/i386/crti.S: No such file or directory.
Missing separate debuginfos, use: zypper install
libgcc_s1-gcc11-32bit-debuginfo-11.0.0+git181412-lp152.1.1.x86_64
...

Breakpoint has correct address, but wrong file and wrong line.

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

[Bug ld/26936] [ld, PIE] ld drops relocation for .text.__x86.get_pc_thunk.bx

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=26936

--- Comment #13 from Tom de Vries  ---
(In reply to H.J. Lu from comment #12)
> (In reply to Tom de Vries from comment #11)
> > (In reply to Tom de Vries from comment #10)
> > > And, reproduced:
> > 
> > To put it in gdb terms:
> > ...
> > $ gdb -q a.out
> > Reading symbols from a.out...
> > (gdb) b  __x86.get_pc_thunk.bx
> > Breakpoint 1 at 0x11d0: file ../sysdeps/i386/crti.S, line 66.
> > (gdb) r
> > Starting program: a.out 
> > Missing separate debuginfos, use: zypper install
> > glibc-32bit-debuginfo-2.26-lp152.26.3.1.x86_64
> > 
> > Breakpoint 1, __x86.get_pc_thunk.bx () at ../sysdeps/i386/crti.S:66
> > 66  ../sysdeps/i386/crti.S: No such file or directory.
> > Missing separate debuginfos, use: zypper install
> > libgcc_s1-gcc11-32bit-debuginfo-11.0.0+git181412-lp152.1.1.x86_64
> > ...
> > 
> > Breakpoint has correct address, but wrong file and wrong line.
> 
> [hjl@gnu-cfl-2 libgcc]$ nm /lib/crti.o
>  T _fini
>  U _GLOBAL_OFFSET_TABLE_
>  w __gmon_start__
>  T _init
>  T __x86.get_pc_thunk.bx
> [hjl@gnu-cfl-2 libgcc]$ 
> 
> 
> You got the right file.

Ah, I see.

So we have __x86.get_pc_thunk.bx in two object files, each with corresponding
debug info.  Due to linkonce in one of them, we only keep one.  The debuginfo
for one object is filled in correctly:
...
crti.S  66  0x11d0   x
crti.S   -  0x11d4
...
the debuginfo for the other becomes incorrect:
...
morestack.S  636   0   x
morestack.S  637 0x3   x
morestack.S- 0x4
...

However, if we look at the non-PIE result we have correct debuginfo for both:
...
crti.S  66   0x8048880   x
crti.S   -   0x8048884
...
and:
...
morestack.S  636   0x8048880   x
morestack.S  637   0x8048883   x
morestack.S-   0x8048884
...

So, AFAIU there's a linker bug here.

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

[Bug binutils/27370] New: [readelf] warning when processing abbrev with DW_FORM_ref_sig8

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=27370

Bug ID: 27370
   Summary: [readelf] warning when processing abbrev with
DW_FORM_ref_sig8
   Product: binutils
   Version: 2.37 (HEAD)
Status: NEW
  Severity: normal
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

...
$ g++ gdb/testsuite/gdb.cp/cpexprs.cc -gdwarf-5 -fdebug-types-section
$ ~/binutils/install/bin/readelf -w a.out > READELF 
readelf: Warning: Unexpected form 20 encountered whilst finding abbreviation
for type
...

The form 20 is actually a hex, so the warning could add a 0x prefix to make
that clear.

The form 0x20 is:
...
DW_FORM (DW_FORM_ref_sig8, 0x20)
...

Putting the warning together with the output, we have:
...
 <2><1839>: Abbrev Number: 48 (DW_TAG_member)
<183a>   DW_AT_name: (indirect string, offset: 0x2065): _sbuf
<183e>   DW_AT_decl_file   : 4
<183f>   DW_AT_decl_line   : 158
<1840>   DW_AT_type: <0x1858>readelf: Warning: Unexpected form 20
encountered whilst finding abbreviation for type

<1844>   DW_AT_data_member_location: 8
...
and the referenced type looks like:
...
 <1><1858>: Abbrev Number: 52 (DW_TAG_pointer_type)
<1859>   DW_AT_byte_size   : 8
<185a>   DW_AT_type: signature: 0xa8df1933f740ec32
...
with abbrev:
...
   52  DW_TAG_pointer_type[no children]
DW_AT_byte_sizeDW_FORM_data1
DW_AT_type DW_FORM_ref_sig8
DW_AT value: 0 DW_FORM value: 0
...

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

[Bug binutils/27371] New: [readelf] .debug_rnglists section header not parsed

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=27371

Bug ID: 27371
   Summary: [readelf] .debug_rnglists section header not parsed
   Product: binutils
   Version: 2.37 (HEAD)
Status: NEW
  Severity: normal
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

...
$ g++ gdb/testsuite/gdb.cp/cpexprs.cc -gdwarf-5 -fdebug-types-section
$ ~/binutils/install/bin/readelf -w a.out 
Contents of the .debug_rnglists section:

Offset   BeginEnd
 readelf: Error: Invalid range list entry type 126
000c 004008c8 004013f1
0017 004013f2 00401407
...

Looking with llvm-dwarfdump:
...
.debug_rnglists contents:
range list header: length = 0x047e, version = 0x0005, addr_size = 0x08,
seg_size = 0x00, offset_entry_count = 0x
ranges:
[0x004008c8, 0x004013f1)
[0x004013f2, 0x00401407)
...

The entry type 126 is 0x7e in hex (which occurs in the length field of the
header).  Looks like the section header is not parsed.

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

[Bug binutils/27386] [readelf] DW_UT_split_compile and DW_UT_skeleton support

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=27386

--- Comment #1 from Tom de Vries  ---
Created attachment 13214
  --> https://sourceware.org/bugzilla/attachment.cgi?id=13214&action=edit
Tentative patch

Does not print dwo_id, but at least manages to print contents of CUs, such that
we have:
...
$ ~/binutils/build/binutils/readelf -w a.out > READELF
$ 
...
and:
...
  Compilation Unit @ offset 0xc7:
   Length:0x31 (32-bit)
   Version:   5
   Unit Type: DW_UT_skeleton (4)
   Abbrev Offset: 0x64
   Pointer Size:  8
 <0>: Abbrev Number: 1 (DW_TAG_skeleton_unit)
   DW_AT_low_pc  : 0x400507
   DW_AT_high_pc : 0x15
   DW_AT_stmt_list   : 0xe9
   DW_AT_dwo_name: (indirect string, offset: 0x1dc): hello.dwo
   DW_AT_comp_dir: (indirect string, offset: 0x1d0): /home/vries
   DW_AT_GNU_pubnames: 1
   DW_AT_GNU_addr_base: 0x0
...
and:
...
  Compilation Unit @ offset 0x0:
   Length:0x229 (32-bit)
   Version:   5
   Unit Type: DW_UT_split_compile (5)
   Abbrev Offset: 0x0
   Pointer Size:  8
 <0><14>: Abbrev Number: 12 (DW_TAG_compile_unit)
<15>   DW_AT_producer: (indexed string: 0x15): GNU C11 7.5.0
-mtune=generic -march=x86-64 -gsplit-dwarf -gdwarf-5
<16>   DW_AT_language: 29   (C11)
<17>   DW_AT_name: (indexed string: 0x36): hello.c
<18>   DW_AT_comp_dir: (indexed string: 0x3a): /home/vries
...

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

[Bug binutils/27386] New: [readelf] DW_UT_split_compile and DW_UT_skeleton support

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=27386

Bug ID: 27386
   Summary: [readelf] DW_UT_split_compile and DW_UT_skeleton
support
   Product: binutils
   Version: 2.37 (HEAD)
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

...
$ gcc -gsplit-dwarf hello.c -gdwarf-5
$ readelf -w a.out > READELF
readelf: Warning: CU at offset c7 contains corrupt or unsupported unit type: 4.
readelf: Warning: CU at offset c7 contains corrupt or unsupported unit type: 4.
...

With llvm-dwarfdump we have:
...
0x00c7: Compile Unit: length = 0x0031 version = 0x0005 unit_type =
DW_UT_skeleton abbr_offset = 0x0064 addr_size = 0x08 DWO_id =
0x49b83479d16a6502 (next unit at 0x00fc)

0x00db: DW_TAG_skeleton_unit
  DW_AT_low_pc  (0x00400507)
  DW_AT_high_pc (0x0040051c)
  DW_AT_stmt_list   (0x00e9)
  DW_AT_dwo_name("hello.dwo")
  DW_AT_comp_dir("/home/vries")
  DW_AT_GNU_pubnames(true)
  DW_AT_GNU_addr_base   (0x)
...

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

[Bug binutils/27386] [readelf] DW_UT_split_compile and DW_UT_skeleton support

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=27386

--- Comment #4 from Tom de Vries  ---
(In reply to Nick Clifton from comment #2)
> Do you think that it would be worth extending the
> gas/testsuite/gas/elf/dwarf-5-cu.[sd] test to include these new unit types ?
> (And maybe the others not already covered).

AFAICT, that test checks the dwarf generated by gas in case there's no
pre-existing dwarf, and then specifically for dwarf-5.

It'd only make sense to check for these unit types if gas would indeed generate
it, which it doesn't AFAIU.

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

[Bug binutils/27370] [readelf] warning when processing abbrev with DW_FORM_ref_sig8

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=27370

Tom de Vries  changed:

   What|Removed |Added

 CC||nickc at redhat dot com

--- Comment #1 from Tom de Vries  ---
Fix:
...
diff --git a/binutils/dwarf.c b/binutils/dwarf.c
index 6797dd158d6..d6eb8926dbf 100644
--- a/binutils/dwarf.c
+++ b/binutils/dwarf.c
@@ -2117,6 +2117,7 @@ get_type_abbrev_from_form (unsigned long
form,
   switch (form)
 {
 case DW_FORM_GNU_ref_alt:
+case DW_FORM_ref_sig8:
   /* FIXME: We are unable to handle this form at the moment.  */
   return NULL;

...

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

[Bug binutils/27370] [readelf] warning when processing abbrev with DW_FORM_ref_sig8

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=27370

--- Comment #2 from Tom de Vries  ---
Posted patch:
https://sourceware.org/pipermail/binutils/2021-February/115294.html

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

[Bug binutils/27371] [readelf] .debug_rnglists section header not parsed

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=27371

--- Comment #1 from Tom de Vries  ---
diff --git a/binutils/dwarf.c b/binutils/dwarf.c
index d6eb8926dbf..9fc040555b4 100644
--- a/binutils/dwarf.c
+++ b/binutils/dwarf.c
@@ -7581,7 +7581,7 @@ display_debug_ranges (struct dwarf_section *section,
   unsigned char *finish = start + bytes;
   unsigned int num_range_list, i;
   struct range_entry *range_entries, *range_entry_fill;
-  int is_rnglists = strstr (section->name, "debug_rnglists") != NULL;
+  int is_rnglists = strstr (section->name, ".debug_rnglists") != NULL;
   /* Initialize it due to a false compiler warning.  */
   unsigned char address_size = 0;
   dwarf_vma last_offset = 0;

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

[Bug binutils/27370] [readelf] warning when processing abbrev with DW_FORM_ref_sig8

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=27370

Tom de Vries  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
   Target Milestone|--- |2.37
 Resolution|--- |FIXED

--- Comment #4 from Tom de Vries  ---
Patch committed, marking resolved-fixed.

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

[Bug binutils/27371] [readelf] .debug_rnglists section header not parsed

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=27371

Tom de Vries  changed:

   What|Removed |Added

 CC||nickc at redhat dot com

--- Comment #2 from Tom de Vries  ---
Patch submitted:
https://sourceware.org/pipermail/binutils/2021-February/115296.html

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

[Bug binutils/27387] New: [readelf] Support -ggdb3 -gsplit-dwarf output

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=27387

Bug ID: 27387
   Summary: [readelf] Support -ggdb3 -gsplit-dwarf output
   Product: binutils
   Version: 2.37 (HEAD)
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

These both are handled without trouble:
...
$ gcc hello.c -ggdb3 
$ ~/binutils/build/binutils/readelf -w a.out > READELF
$ gcc hello.c -gsplit-dwarf
$ ~/binutils/build/binutils/readelf -w a.out > READELF
...

But both combined:
...
$ gcc hello.c -ggdb3 -gsplit-dwarf
$ readelf -w a.out > READELF
readelf: Error: Only GNU extension to DWARF 4 or 5 of .debug_macro.dwo is
currently supported.
readelf: Error:  Unknown macro opcode d4 seen
readelf: Error:  Unknown macro opcode a1 seen
readelf: Error: /home/vries/binutils/src/binutils/dwarf.c:6028: end of data
encountered whilst reading LEB
readelf: Error: DW_MACRO_start_file used, but no .debug_line offset provided.
readelf: Error: .debug_macro section not zero terminated
readelf: Error:  Unknown macro opcode bf seen
readelf: Error:  Unknown macro opcode 5f seen
readelf: Error:  Unknown macro opcode ce seen
readelf: Error: DW_MACRO_start_file used, but no .debug_line offset provided.
readelf: Error:  Unknown macro opcode bc seen
readelf: Error:  Unknown macro opcode 4f seen
readelf: Error:  Unknown macro opcode b2 seen
readelf: Error:  Unknown macro opcode 3c seen
readelf: Error: .debug_macro section not zero terminated
readelf: Error: .debug_macro section not zero terminated
readelf: Error:  Unknown macro opcode 81 seen
readelf: Error: DW_MACRO_start_file used, but no .debug_line offset provided.
readelf: Error:  Unknown macro opcode 3c seen
readelf: Error: DW_MACRO_start_file used, but no .debug_line offset provided.
readelf: Error:  Unknown macro opcode 96 seen
readelf: Error: DW_MACRO_start_file used, but no .debug_line offset provided.
readelf: Error:  Unknown macro opcode ca seen
readelf: Error:  Unknown macro opcode d4 seen
readelf: Error:  Unknown macro opcode d8 seen
readelf: Error:  Unknown macro opcode 9d seen
readelf: Error:  Unknown macro opcode c5 seen
readelf: Error: .debug_macro section not zero terminated
readelf: Error: .debug_macro section not zero terminated
...

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

[Bug binutils/27387] [readelf] Support -ggdb3 -gsplit-dwarf output

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=27387

--- Comment #1 from Tom de Vries  ---
This looks a bit weird though:
...
$ readelf -S -W hello.dwo 
There are 32 section headers, starting at offset 0x3028:

Section Headers:
  [Nr] Name  TypeAddress  OffSize   ES Flg
Lk Inf Al
  [ 0]   NULL 00 00 00 
0   0  0
  [ 1] .debug_info.dwo   PROGBITS 40 0001fe 00  CE 
0   0  8
  [ 2] .debug_abbrev.dwo PROGBITS 000240 b6 00  CE 
0   0  8
  [ 3] .debug_macro.dwo  PROGBITS 0002f8 b3 00  CE 
0   0  8
  [ 4] .debug_macro.dwo  PROGBITS 0003b0 000313 00   C 
0   0  8
  [ 5] .debug_macro.dwo  PROGBITS 0006c3 17 00 
0   0  1
  [ 6] .debug_macro.dwo  PROGBITS 0006da 0c 00 
0   0  1
  [ 7] .debug_macro.dwo  PROGBITS 0006e8 00010f 00   C 
0   0  8
  [ 8] .debug_macro.dwo  PROGBITS 0007f7 f4 00 
0   0  1
  [ 9] .debug_macro.dwo  PROGBITS 0008eb 10 00 
0   0  1
  [10] .debug_macro.dwo  PROGBITS 0008fb 34 00 
0   0  1
  [11] .debug_macro.dwo  PROGBITS 00092f 39 00 
0   0  1
  [12] .debug_macro.dwo  PROGBITS 000968 23 00 
0   0  1
  [13] .debug_macro.dwo  PROGBITS 00098b 0b 00 
0   0  1
  [14] .debug_macro.dwo  PROGBITS 000996 67 00 
0   0  1
  [15] .debug_macro.dwo  PROGBITS 0009fd 3f 00 
0   0  1
  [16] .debug_macro.dwo  PROGBITS 000a3c 9c 00 
0   0  1
  [17] .debug_macro.dwo  PROGBITS 000ad8 0e 00 
0   0  1
  [18] .debug_macro.dwo  PROGBITS 000ae6 18 00 
0   0  1
  [19] .debug_macro.dwo  PROGBITS 000afe 1a 00 
0   0  1
  [20] .debug_macro.dwo  PROGBITS 000b18 3c 00 
0   0  1
  [21] .debug_macro.dwo  PROGBITS 000b54 0c 00 
0   0  1
  [22] .debug_macro.dwo  PROGBITS 000b60 000127 00   C 
0   0  8
  [23] .debug_macro.dwo  PROGBITS 000c87 2e 00 
0   0  1
  [24] .debug_macro.dwo  PROGBITS 000cb5 1f 00 
0   0  1
  [25] .debug_macro.dwo  PROGBITS 000cd4 1b 00 
0   0  1
  [26] .debug_line.dwo   PROGBITS 000cf0 000117 00  CE 
0   0  8
  [27] .debug_str_offsets.dwo PROGBITS 000e08 0004e8 00
 CE  0   0  8
  [28] .debug_str.dwoPROGBITS 0012f0 0019f4 00  CE 
0   0  8
  [29] .symtab   SYMTAB   002ce8 0002b8 18
30  29  8
  [30] .strtab   STRTAB   002fa0 01 00 
0   0  1
  [31] .shstrtab STRTAB   002fa1 84 00 
0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
  L (link order), O (extra OS processing required), G (group), T (TLS),
  C (compressed), x (unknown), o (OS specific), E (exclude),
  l (large), p (processor specific)
...

Why do we have so many .debug_macro.dwo sections?

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

[Bug binutils/27371] [readelf] .debug_rnglists section header not parsed

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=27371

--- Comment #4 from Tom de Vries  ---
(In reply to Nick Clifton from comment #3)
> (In reply to Tom de Vries from comment #1)
> Hi Tom,
> 
> I do not quite get this:
> 
>   > -  int is_rnglists = strstr (section->name, "debug_rnglists") != NULL;
>   > +  int is_rnglists = strstr (section->name, ".debug_rnglists") != NULL;
> 
> The strstr() function locates a sub-string within a a longer string,
> so won't both versions of the code above produce the same results ?
> 
> I think that the reason that the test did not include the "." prefix
> was that it is meant to work with compressed range list sections as
> well, ie .zdebug_rnglists.

Hi Nick,

you're right, this is incorrect.  Alan had the same comment.  I've resubmitted
here: https://sourceware.org/pipermail/binutils/2021-February/115309.html

Thanks,
- Tom

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

[Bug binutils/27386] [readelf] DW_UT_split_compile and DW_UT_skeleton support

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=27386

Tom de Vries  changed:

   What|Removed |Added

   Target Milestone|--- |2.37
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Tom de Vries  ---
Patch committed.  Tentatively marking this resolved-fixed.

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

[Bug binutils/27390] New: [readelf] Support DW_FORM_strx1 and DW_FORM_addrx

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=27390

Bug ID: 27390
   Summary: [readelf] Support DW_FORM_strx1 and DW_FORM_addrx
   Product: binutils
   Version: 2.37 (HEAD)
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

...
$ clang hello.c -gdwarf-5  
$ readelf -w a.out > READELF
readelf: Warning: Unrecognized form: 37
readelf: Warning: Unrecognized form: 37
readelf: Warning: Unrecognized form: 37
readelf: Warning: Unsupported form (DW_FORM_strx1) for attribute DW_AT_comp_dir
readelf: Warning: Unrecognized form: 27
readelf: Warning: DIE at offset 0xe6 refers to abbreviation number 8 which does
not exist
readelf: Warning: Unrecognized form: 37
readelf: Warning: Unrecognized form: 37
readelf: Warning: Unrecognized form: 37
readelf: Warning: Unsupported form (DW_FORM_strx1) for attribute DW_AT_comp_dir
readelf: Warning: Unrecognized form: 27
readelf: Warning: DIE at offset 0xe6 refers to abbreviation number 8 which does
not exist
readelf: Warning: Unrecognized form: 37
readelf: Warning: Unrecognized form: 37
readelf: Warning: Unrecognized form: 37
readelf: Warning: Unrecognized form: 27
readelf: Warning: DIE at offset 0xe6 refers to abbreviation number 8 which does
not exist
readelf: Warning: Unable to load/parse the .debug_info section, so cannot
interpret the .debug_loc section.
readelf: Warning: Unable to load/parse the .debug_info section, so cannot
interpret the .debug_ranges section.
readelf: Warning: Unable to load/parse the .debug_info section, so cannot
interpret the .debug_addr section.
...

Form 37: 0x25: DW_FORM_strx1

Form 27: 0x1b: DW_FORM_addrx

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

[Bug binutils/27371] [readelf] .debug_rnglists section header not parsed

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=27371

Tom de Vries  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED
   Target Milestone|--- |2.37

--- Comment #6 from Tom de Vries  ---
Patch committed, marking resolved-fixed.

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

[Bug binutils/27391] New: [readelf] Handle absolute DW_AT_dwo_name

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=27391

Bug ID: 27391
   Summary: [readelf] Handle absolute DW_AT_dwo_name
   Product: binutils
   Version: 2.37 (HEAD)
Status: NEW
  Severity: normal
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

With the fission-mix executable from the gdb testsuite, I run into:
...
$ ~/binutils/install/bin/readelf -w fission-mix > READELF
readelf: Warning: Unable to load dwo file:
/home/vries/gdb_versions/devel/build/gdb/testsuite//home/vries/gdb_versions/devel/build/gdb/testsuite/outputs/gdb.dwarf2/fission-mix/fission-mix2.dwo
...

At the start we find:
...
The .debug_info section contains link(s) to dwo file(s):

  Name: 
/home/vries/gdb_versions/devel/build/gdb/testsuite/outputs/gdb.dwarf2/fission-mix/fission-mix2.dwo
  Directory: /home/vries/gdb_versions/devel/build/gdb/testsuite
  ID:
...
and later-on the part from where we get this info:
...
  Compilation Unit @ offset 0x176:
   Length:0x31 (32-bit)
   Version:   5
   Unit Type: DW_UT_skeleton (4)
   Abbrev Offset: 0xfd
   Pointer Size:  8
 <0><18a>: Abbrev Number: 1 (DW_TAG_skeleton_unit)
<18b>   DW_AT_low_pc  : 0x4004cf
<193>   DW_AT_high_pc : 0x15
<19b>   DW_AT_stmt_list   : 0x14d
<19f>   DW_AT_dwo_name:
/home/vries/gdb_versions/devel/build/gdb/testsuite/outputs/gdb.dwarf2/fission-mix/fission-mix2.dwo
<1a3>   DW_AT_comp_dir:
/home/vries/gdb_versions/devel/build/gdb/testsuite
<1a7>   DW_AT_GNU_pubnames: 1
<1a7>   DW_AT_addr_base   : 0x8
...

In the dwarf-5 standard we read:
...
A skeleton compilation unit has a DW_AT_dwo_name attribute:
1. A DW_AT_dwo_name attribute whose value is a null-terminated string
containing the full or relative path name (relative to the value of the
DW_AT_comp_dir attribute, see below) of the object file that contains the full
compilation unit.
...

So, the name only needs to be prefixed with the dir if it's relative.

In this case, the name is already absolute and readelf shouldn't try to add the
dir prefix.

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

[Bug binutils/27391] [readelf] Handle absolute DW_AT_dwo_name

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=27391

--- Comment #1 from Tom de Vries  ---
Tentative patch:
...
diff --git a/binutils/dwarf.c b/binutils/dwarf.c
index 84d63f63366..3cbd19710d7 100644
--- a/binutils/dwarf.c
+++ b/binutils/dwarf.c
@@ -11092,8 +11092,11 @@ load_dwo_file (const char * main_filename, const char
* name,
 const char * dir,
   char * separate_filename;
   void * separate_handle;

-  /* FIXME: Skip adding / if dwo_dir ends in /.  */
-  separate_filename = concat (dir, "/", name, NULL);
+  if (IS_ABSOLUTE_PATH (name))
+separate_filename = strdup (name);
+  else
+/* FIXME: Skip adding / if dwo_dir ends in /.  */
+separate_filename = concat (dir, "/", name, NULL);
   if (separate_filename == NULL)
 {
   warn (_("Out of memory allocating dwo filename\n"));
...

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

[Bug binutils/27391] [readelf] Handle absolute DW_AT_dwo_name

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=27391

--- Comment #2 from Tom de Vries  ---
submitted here:
https://sourceware.org/pipermail/binutils/2021-February/115314.html

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

[Bug binutils/27391] [readelf] Handle absolute DW_AT_dwo_name

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=27391

Tom de Vries  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
   Target Milestone|--- |2.37
 Resolution|--- |FIXED

--- Comment #4 from Tom de Vries  ---
Patch committed, marking resolved-fixed.

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

[Bug binutils/27390] [readelf] Support DW_FORM_strx1 and DW_FORM_addrx

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=27390

--- Comment #2 from Tom de Vries  ---
Created attachment 13216
  --> https://sourceware.org/bugzilla/attachment.cgi?id=13216&action=edit
Tentative patch

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

[Bug binutils/27390] [readelf] Support DW_FORM_strx1 and DW_FORM_addrx

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=27390

--- Comment #3 from Tom de Vries  ---
Created attachment 13217
  --> https://sourceware.org/bugzilla/attachment.cgi?id=13217&action=edit
a.out.gz

Produced using:
...
$ clang hello.c -gdwarf-5
...

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

[Bug binutils/27390] [readelf] Support DW_FORM_strx1 and DW_FORM_addrx

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=27390

--- Comment #4 from Tom de Vries  ---
(In reply to Tom de Vries from comment #2)
> Created attachment 13216 [details]
> Tentative patch

FWIW, doesn't work yet with split dwarf.  The DW_AT_addr_base is defined in the
skeleton CU, and the DW_FORM_addrx uses are in the split CU, and readelf
doesn't manage to figure out that those go together.

Currently we end up with:
...
<4b>   DW_AT_low_pc  : (addr_index: 0x0): 
...
so it looks like it doesn't even realize that the .debug_addr in a.out should
be used for hello.dwo.

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

[Bug gas/27215] as: Error: non-constant .uleb128 is not supported on riscv64

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=27215

Tom de Vries  changed:

   What|Removed |Added

 CC||vries at gcc dot gnu.org

--- Comment #3 from Tom de Vries  ---
Comment from dwz ml ( https://sourceware.org/pipermail/dwz/2021q1/000988.html
):
...
> The construct seems like it is represented by a known constant at compile 
> time:
> 
> .uleb128.Lexpr_end4 - .Lexpr_start3/* expression */ 
> .Lexpr_start3: 
> .byte0xf2   /* DW_OP_GNU_implicit_pointer */ 
> .4byte.Llabel2 
> .sleb1280 
> .Lexpr_end4: 
> 
> There isn't anything between the two labels that can have a variable
> size.  So it might be a good idea to file a bug report against
> binutils as for not allowing this on riscv64.

I believe the riscv people explain it by aggressive linker optimizations
that make those not to work, but perhaps that applies to normal sections,
but don't see how can that apply to .debug* sections...
They shouldn't be doing any kind of aggressive linker relaxations on
.debug*.
...

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

[Bug gas/27215] as: Error: non-constant .uleb128 is not supported on riscv64

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=27215

--- Comment #4 from Tom de Vries  ---
Cross-referencing gcc PR https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99090

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

[Bug binutils/27387] [readelf] Support -ggdb3 -gsplit-dwarf output

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=27387

--- Comment #4 from Tom de Vries  ---
Created attachment 13267
  --> https://sourceware.org/bugzilla/attachment.cgi?id=13267&action=edit
hello.dwo.gz

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

[Bug binutils/27387] [readelf] Support -ggdb3 -gsplit-dwarf output

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=27387

--- Comment #3 from Tom de Vries  ---
Created attachment 13266
  --> https://sourceware.org/bugzilla/attachment.cgi?id=13266&action=edit
a.out.gz

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