[Bug binutils/27809] RISC-V missing disassembler options in document

[nelsonc1225 at sourceware dot org]

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

Nelson Chu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Nelson Chu  ---
Should be fixed in the commit 3a337a86, so marked as resolved and fixed.
https://github.com/bminor/binutils-gdb/commit/3a337a86d9d273b5da57b1cd8ecec4baa7e95e33

commit 3a337a86d9d273b5da57b1cd8ecec4baa7e95e33
Refs: gdb-11-branchpoint-1308-g3a337a86d9d
Author: Andrew Burgess 
AuthorDate: Tue Sep 28 22:11:42 2021 +0100
Commit: Andrew Burgess 
CommitDate: Fri Nov 26 10:18:35 2021 +

opcodes/riscv: add disassembler options support to libopcodes

In preparation for the next commit, which will add GDB support for
RISC-V disassembler options, this commit restructures how the
disassembler options are managed within libopcodes.

The implementation provided here is based on this mailing list patch
which was never committed:

  https://sourceware.org/pipermail/binutils/2021-January/114944.html

which in turn took inspiration from the MIPS implementation of the
same feature.

The biggest changes from the original mailing list post are:

  1. The GDB changes have been split into a separate patch, and

  2. The `riscv_option_args_privspec` variable, which held the valid
  priv-spec values is now gone, instead we use the `riscv_priv_specs`
  array from bfd/cpu-riscv.c instead.

Co-authored-by: Simon Cook 

include/ChangeLog:

* dis-asm.h (disassembler_options_riscv): Declare.

opcodes/ChangeLog:

* riscv-dis.c (enum riscv_option_arg_t): New enum typedef.
(riscv_options): New static global.
(disassembler_options_riscv): New function.
(print_riscv_disassembler_options): Rewrite to use
disassembler_options_riscv.

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

[Bug ld/24683] RISC-V call and callplt reloc handling

[nelsonc1225 at sourceware dot org]

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

Nelson Chu  changed:

   What|Removed |Added

 CC||nelsonc1225 at sourceware dot 
org
 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Nelson Chu  ---
Anyway, we should have the same behavior of CALL and CALL_PLT both in GNU and
LLVM, so marked this as RESOLVED and FIXED.

Btw, Psabi now suggest to use CALL_PLT, and deprecate CALL,
https://github.com/riscv-non-isa/riscv-elf-psabi-doc/commit/a0dced85018d7a0ec17023c9389cbd70b1dbc1b0

commit 3b1450b38c644f99aa2e211747b428b9f8d15cca
Refs: gdb-9-branchpoint-3394-g3b1450b38c6
Author: Nelson Chu 
AuthorDate: Wed Aug 26 01:19:13 2020 -0700
Commit: Nelson Chu 
CommitDate: Fri Aug 28 09:37:35 2020 +0800

RISC-V: Treat R_RISCV_CALL and R_RISCV_CALL_PLT as the same in
check_relocs.

In fact, we can treate these two relocation as the same one in the
riscv_elf_check_relocs.  I have heard that RISC-V lld had made this
improvement, and so had GNU AARCH64, they only need R_AARCH64_CALL26
for calls rather than two seperate relocations.

Beside, the following PLT issue for RISC-V 32-bit glibc seems to be
fixed by applying at least this patch.



I have ran the toolchain regression, and everything seems fine for now.

bfd/
* elfnn-riscv.c (riscv_elf_check_relocs): Treat R_RISCV_CALL
and R_RISCV_CALL_PLT as the same in the riscv_elf_check_relocs.
(riscv_elf_relocate_section): Remove the R_RISCV_CALL for the
unresolved reloc checks.

ld/
testsuite/ld-riscv-elf/lib-nopic-01a.s: Use R_RISCV_JAL rather
than R_RISCV_CALL.
testsuite/ld-riscv-elf/lib-nopic-01b.d: Likewise.
testsuite/ld-riscv-elf/lib-nopic-01b.s: Likewise.

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

[Bug gas/28863] two-argument .align is accepted for RISC-V but the alignment is not always preserved

[nelsonc1225 at sourceware dot org]

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

Nelson Chu  changed:

   What|Removed |Added

 CC||nelsonc1225 at sourceware dot 
org

--- Comment #1 from Nelson Chu  ---
Seems like the second argument of .aign cannot work unless -mno-relax is used,
so we need to fix this as it should be a bug.

% cat tmp.s
.text
.globl _start
_start:
add a0, a0, a0
add a0, a0, a0
.align  4
foo:
add a0, a0, a0

.align  4, 1
bar:
add a0, a0, a0
% riscv64-unknown-elf-as tmp.s -o tmp.o
% riscv64-unknown-elf-objdump -d tmp.o 

tmp.o: file format elf64-littleriscv


Disassembly of section .text:

 <_start>:
   0:   00a50533add a0,a0,a0
   4:   00a50533add a0,a0,a0
   8:   0013nop
   c:   0013nop
  10:   0013nop --> correct, add 2^4 - 4 (norvc) nops

0014 :
  14:   00a50533add a0,a0,a0
  18:   01010101.word   0x01010101
  1c:   01010101.word   0x01010101  --> looks like we just
align it
without consider the ld
relax

0020 :
  20:   00a50533add a0,a0,a0
...

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

[Bug gas/29523] i686-w64-mingw32-objdump -WL returns incorrect file paths

[nickc at redhat dot com]

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

--- Comment #7 from Nick Clifton  ---
Created attachment 14318
  --> https://sourceware.org/bugzilla/attachment.cgi?id=14318&action=edit
Proposed Patch

Hi Ralf,

  Stupid DWARF-5, it has been the bane of my existence recently.

  This is another of the DWARF-5-indexes-file/dir-tables-from-0 bugs.

  Please try out the uploaded patch and let me know if it works for you.

Cheers
  Nick

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

[Bug gas/29523] i686-w64-mingw32-objdump -WL returns incorrect file paths

[nickc at redhat dot com]

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

Nick Clifton  changed:

   What|Removed |Added

   Assignee|unassigned at sourceware dot org   |nickc at redhat dot com
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2022-09-06
 Ever confirmed|0   |1

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

[Bug binutils/29075] objdump -S does not support debuginfod

[amerey at redhat dot com]

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

Aaron Merey  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #28 from Aaron Merey  ---
(In reply to Nick Clifton from comment #27)
> Patches approved.  Please apply both.

Thanks Nick, pushed as commits 6e7a29c7d and d647c797b.

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

[Bug gas/29551] New: Wrong relocations against _GLOBAL_OFFSET_TABLE_

[hjl.tools at gmail dot com]

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

Bug ID: 29551
   Summary: Wrong relocations against _GLOBAL_OFFSET_TABLE_
   Product: binutils
   Version: 2.40 (HEAD)
Status: NEW
  Severity: normal
  Priority: P2
 Component: gas
  Assignee: unassigned at sourceware dot org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---
Target: i386,x86-64

[hjl@gnu-tgl-3 tmp]$ cat 32.s 
.text
movl $_GLOBAL_OFFSET_TABLE_, %eax
.data
.long _GLOBAL_OFFSET_TABLE_
[hjl@gnu-tgl-3 tmp]$ gcc -c 32.s -m32 
[hjl@gnu-tgl-3 tmp]$ readelf -r 32.o

Relocation section '.rel.text' at offset 0xa0 contains 1 entry:
 Offset InfoTypeSym.Value  Sym. Name
0001  010a R_386_GOTPC      _GLOBAL_OFFSET_TABLE_

Relocation section '.rel.data' at offset 0xa8 contains 1 entry:
 Offset InfoTypeSym.Value  Sym. Name
  010a R_386_GOTPC      _GLOBAL_OFFSET_TABLE_
[hjl@gnu-tgl-3 tmp]$ 

R_386_32 should be used.

[hjl@gnu-tgl-3 tmp]$ cat 64.s 
.text
movl $_GLOBAL_OFFSET_TABLE_, %eax
movq _GLOBAL_OFFSET_TABLE_@GOTPCREL(%rip), %rax
.data
.quad _GLOBAL_OFFSET_TABLE_
[hjl@gnu-tgl-3 tmp]$ gcc -c 64.s
[hjl@gnu-tgl-3 tmp]$ readelf -rW 64.o

Relocation section '.rela.text' at offset 0xd0 contains 2 entries:
Offset Info Type   Symbol's Value 
Symbol's Name + Addend
0001  0001001a R_X86_64_GOTPC32   
_GLOBAL_OFFSET_TABLE_ + 1
0008  00010019 R_X86_64_GOTOFF64  
_GLOBAL_OFFSET_TABLE_ - 4

Relocation section '.rela.data' at offset 0x100 contains 1 entry:
Offset Info Type   Symbol's Value 
Symbol's Name + Addend
  0001001d R_X86_64_GOTPC64   
_GLOBAL_OFFSET_TABLE_ + 0
[hjl@gnu-tgl-3 tmp]$ 

Relocations should be

[hjl@gnu-tgl-3 tmp]$ readelf -rW 64x.o 

Relocation section '.rela.text' at offset 0xe8 contains 2 entries:
Offset Info Type   Symbol's Value 
Symbol's Name + Addend
0001  0001000a R_X86_64_32
_GLOBAL_OFFSET_TABLE_ + 0
0008  0001002a R_X86_64_REX_GOTPCRELX 
_GLOBAL_OFFSET_TABLE_ - 4

Relocation section '.rela.data' at offset 0x118 contains 1 entry:
Offset Info Type   Symbol's Value 
Symbol's Name + Addend
  00010001 R_X86_64_64
_GLOBAL_OFFSET_TABLE_ + 0
[hjl@gnu-tgl-3 tmp]$

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

[Bug gas/29551] Wrong relocations against _GLOBAL_OFFSET_TABLE_

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=106834

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

[Bug gas/29551] Wrong relocations against _GLOBAL_OFFSET_TABLE_

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=106835

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

[Bug ld/29552] New: [GCC 12.2] the address of ‘elf_header’ will never be NULL [-Werror=address]

[hjl.tools at gmail dot com]

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

Bug ID: 29552
   Summary: [GCC 12.2] the address of ‘elf_header’ will never be
NULL [-Werror=address]
   Product: binutils
   Version: 2.40 (HEAD)
Status: NEW
  Severity: normal
  Priority: P2
 Component: ld
  Assignee: unassigned at sourceware dot org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

GCC 12.2 failed to build binutils master branch:

/export/gnu/import/git/sources/binutils-gdb/ld/ldelf.c: In function
‘ldelf_after_open’:
/export/gnu/import/git/sources/binutils-gdb/ld/ldelf.c:1049:43: error: the
comparison will always evaluate as ‘true’ for the address of ‘elf_header’ will
never be NULL [-Werror=address]
 1049 |   && elf_tdata (abfd)->elf_header != NULL 
  |   ^~
In file included from
/export/gnu/import/git/sources/binutils-gdb/ld/ldelf.c:37:
/export/gnu/import/git/sources/binutils-gdb/ld/../bfd/elf-bfd.h:1930:21: note:
‘elf_header’ declared here 
 1930 |   Elf_Internal_Ehdr elf_header[1];  /* Actual data, but ref like
ptr */
  | ^~

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

[Bug ld/29552] [GCC 12.2] the address of ‘elf_header’ will never be NULL [-Werror=address]

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from H.J. Lu  ---
Wrong branch.

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

[Bug gas/29551] Wrong relocations against _GLOBAL_OFFSET_TABLE_

[hjl.tools at gmail dot com]

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

--- Comment #1 from H.J. Lu  ---
GCC generates

call__x86.get_pc_thunk.bx
addl$_GLOBAL_OFFSET_TABLE_, %ebx

to load the address of _GLOBAL_OFFSET_TABLE_ into EBX with R_386_GOTPC
relocation.

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

[Bug gprofng/29477] Build failure on musl: collector_module.h:78:13: error: duplicate member ‘pwrite’

[sam at gentoo dot org]

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

--- Comment #5 from Sam James  ---
You can also try, per #musl on IRC's recommendations, http://musl.cc/ which is
designed for this sort of thing.

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

[Bug gas/29551] Wrong relocations against _GLOBAL_OFFSET_TABLE_

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  ---
We can't change _GLOBAL_OFFSET_TABLE_ nor _GLOBAL_OFFSET_TABLE_(%rip).
_GLOBAL_OFFSET_TABLE_ generates GOTPC32 relocation. 
_GLOBAL_OFFSET_TABLE_(%rip)
generates GOTPC32 relocation which is the same as PC32 since symbol is GOT.

But we should handle _GLOBAL_OFFSET_TABLE_@GOTPCREL(%rip).
i386_displacement first generates BFD_RELOC_X86_64_GOTPCREL for
symbol@GOTPCREL(%rip).  Then i386_finalize_displacement changes it
to BFD_RELOC_32_PCREL.  Before i386_validate_fix changes BFD_RELOC_32_PCREL
back to BFD_RELOC_X86_64_GOTPCREL, output_disp changes BFD_RELOC_32_PCREL
to BFD_RELOC_X86_64_GOTPC32 because symbol == _GLOBAL_OFFSET_TABLE_.

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

[Bug gas/29527] x86: ambiguous operands silently accepted in AT&T mode

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  ---
(In reply to Jan Beulich from comment #0)
>   cvtsi2ss (%rax), %xmm0
>   vcvtsi2ss (%rax), %xmm0, %xmm0
>   vcvtusi2ss (%rax), %xmm0, %xmm0
> 

They default to 32 bits because when SSE was introduced, it was 32-bit only.

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

[Bug gas/29551] Wrong relocations against _GLOBAL_OFFSET_TABLE_

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||jbeulich at suse dot com

--- Comment #3 from H.J. Lu  ---
commit d6ab8113e32876e3d8ca06ad090d3160d51c8e16
Author: Jan Beulich 
Date:   Fri Jun 17 08:03:59 2005 +

has

(output_disp): Do GOTPC conversion also for BFD_RELOC_X86_64_32S
and BFD_RELOC_32_PCREL. Use BFD_RELOC_X86_64_GOTPC32 instead of
aborting.

Remove || reloc_type == BFD_RELOC_32_PCREL) seems to work.

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

[Bug gas/29523] i686-w64-mingw32-objdump -WL returns incorrect file paths

[ralf.habacker at freenet dot de]

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

--- Comment #8 from Ralf Habacker  ---
(In reply to Nick Clifton from comment #7)
Hi Nick,


>   Please try out the uploaded patch and let me know if it works for you.

Thank you for your support.

Unfortunally the patch does not seem to fit on the git master branch

user@host:~/src/binutils-gdb> git remote -v
origin  git://sourceware.org/git/binutils-gdb.git (fetch)
origin  git://sourceware.org/git/binutils-gdb.git (push)

user@host:~/src/binutils-gdb> git branch
master

user@host:~/src/binutils-gdb> git pull --rebase

user@host:~/src/binutils-gdb> git apply ~/Downloads/pr29523.txt
error: Failed to apply the patch: binutils/dwarf.c:5215
error: binutils/dwarf.c: patch could not be applied

Can you rebase it ?

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

[Bug gas/29527] x86: ambiguous operands silently accepted in AT&T mode

[jbeulich at suse dot com]

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

--- Comment #3 from Jan Beulich  ---
(In reply to H.J. Lu from comment #2)
> (In reply to Jan Beulich from comment #0)
> > cvtsi2ss (%rax), %xmm0
> > vcvtsi2ss (%rax), %xmm0, %xmm0
> > vcvtusi2ss (%rax), %xmm0, %xmm0
> > 
> 
> They default to 32 bits because when SSE was introduced, it was 32-bit only.

How does "32-bit only" at introduction time matter for 64-bit? When 64-bit was
introduced, disambiguation should have been required (and 32-bit code would
have remained unaffected). In fact the lack thereof had allowed a gcc bug to go
unnoticed for quite some time.

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