[Bug gprofng/30779] gprofng: fails to build with musl-1.2.4 (gprofng/src/Data_window.h:56:3: error: 'off64_t' does not name a type; did you mean 'off_t'?)
https://sourceware.org/bugzilla/show_bug.cgi?id=30779 --- Comment #8 from Sourceware Commits --- The master branch has been updated by Vladimir Mezentsev : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=576d2c97d8de26d1ab5a2058e8ba4ffd00b8096d commit 576d2c97d8de26d1ab5a2058e8ba4ffd00b8096d Author: Vladimir Mezentsev Date: Thu Dec 21 21:33:58 2023 -0800 gprofng: fix build problems on linux-musl ino64_t, off64_t, fpos64_t, stat64, __u64 are not defined on linux-musl. Fixed by declaring these types for linux-musl. 2023-12-21 Vladimir Mezentsev PR gprofng/30779 PR gprofng/29593 * common/gp-defs.h: Define ino64_t, off64_t, fpos64_t for linux-musl. * libcollector/unwind.c: Define __u64 for linux-musl. * src/util.h: Define dbe_stat_t. * src/ClassFile.cc: Use dbe_stat_t instead of "struct stat64". * src/Dbe.cc: Likewise. * src/DbeFile.cc: Likewise. * src/DbeFile.h: Likewise. * src/DbeSession.cc: Likewise. * src/Experiment.cc: Likewise. * src/checks.cc: Likewise. * src/util.cc: Likewise. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/29593] error: '__u64' undeclared (first use in this function) for aarch64-linux-musl host
https://sourceware.org/bugzilla/show_bug.cgi?id=29593 --- Comment #3 from Sourceware Commits --- The master branch has been updated by Vladimir Mezentsev : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=576d2c97d8de26d1ab5a2058e8ba4ffd00b8096d commit 576d2c97d8de26d1ab5a2058e8ba4ffd00b8096d Author: Vladimir Mezentsev Date: Thu Dec 21 21:33:58 2023 -0800 gprofng: fix build problems on linux-musl ino64_t, off64_t, fpos64_t, stat64, __u64 are not defined on linux-musl. Fixed by declaring these types for linux-musl. 2023-12-21 Vladimir Mezentsev PR gprofng/30779 PR gprofng/29593 * common/gp-defs.h: Define ino64_t, off64_t, fpos64_t for linux-musl. * libcollector/unwind.c: Define __u64 for linux-musl. * src/util.h: Define dbe_stat_t. * src/ClassFile.cc: Use dbe_stat_t instead of "struct stat64". * src/Dbe.cc: Likewise. * src/DbeFile.cc: Likewise. * src/DbeFile.h: Likewise. * src/DbeSession.cc: Likewise. * src/Experiment.cc: Likewise. * src/checks.cc: Likewise. * src/util.cc: Likewise. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31179] RISC-V: The SET/ADD/SUB fix breaks ABI compatibility with 2.41 objects
https://sourceware.org/bugzilla/show_bug.cgi?id=31179
Charlie Jenkins changed:
What|Removed |Added
CC||charlie at rivosinc dot com
--- Comment #10 from Charlie Jenkins ---
>From a9eb35c3ee0eb265674d7858a8b4ec24928eae6e Mon Sep 17 00:00:00 2001
>From: Nelson Chu
>Date: Wed, 20 Dec 2023 10:37:41 +0800
>Subject: [PATCH] RISC-V: PR31179, The SET/ADD/SUB fix breaks ABI compatibility
> with 2.41 objects
>
>* Problematic fix commit,
>2029e13917d53d2289d3ebb390c4f40bd2112d21
>RISC-V: Clarify the behaviors of SET/ADD/SUB relocations
...
>
>+ _bfd_error_handler (_("%pB: warning: R_RISCV_SUB_ULEB128 with"
>+" non-zero addend, please rebuild by new"
>+" binutils"), input_bfd);
Is it possible to provide a version number instead of saying "new"? Then you
could say something like "please rebuild using a binutils that is at least
version 2.42".
...
> PARSE_AND_LIST_OPTIONS=${PARSE_AND_LIST_OPTIONS}'
> fprintf (file, _(" --relax-gp Perform GP relaxation\n"));
> fprintf (file, _(" --no-relax-gp Don'\''t perform GP
> relaxation\n"));
>+ fprintf (file, _(" --check-uleb128 Check if SUB_ULEB128 with
>non-zero addend\n"));
I think it is more clear here to replace "with" with "has".
>+ fprintf (file, _(" --no-check-uleb128 Don'\''t check if
>SUB_ULEB128 with non-zero addend\n"));
Same thing here.
...
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug gas/31178] [2.42 regression] Crash when building Valgrind tests (Internal error in build_vex_prefix in tc-i386.c:376)
https://sourceware.org/bugzilla/show_bug.cgi?id=31178 H.J. Lu changed: What|Removed |Added CC||hjl.tools at gmail dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31179] RISC-V: The SET/ADD/SUB fix breaks ABI compatibility with 2.41 objects
https://sourceware.org/bugzilla/show_bug.cgi?id=31179 --- Comment #9 from Palmer Dabbelt --- (In reply to Nelson Chu from comment #8) > Created attachment 15270 [details] > proposed solution with the tag to keep compatible > > Updated to have a tag, this patch should be applied after the proposed v1 > patch. > > The object which marked by the tag means it won't have any non-zero ddend in > SUB_ULEB128 from .uleb128 directives, so we don't need to ignore them to get > the > correct calculation in linker. > > Since the tag is non-standard in riscv psabi, so need use > elf_other_obj_attributes_proc rather than elf_known_obj_attributes_proc api > to access. Thanks Nelson, that was super fast ;) So I think this is a roughly workable solution (maybe we should cache those tag lookups for performance, not sure if it matters). It's going to be hard to tell for sure without some distro testing, though. Does this pass the toolchain regressions? If so, I think we should poke the distro folks (many of whom I guess who are here) to see if it's actually resolving their issues. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/31178] [2.42 regression] Crash when building Valgrind tests (Internal error in build_vex_prefix in tc-i386.c:376)
https://sourceware.org/bugzilla/show_bug.cgi?id=31178 Sam James changed: What|Removed |Added CC||jbeulich at suse dot com --- Comment #3 from Sam James --- da0784f961d8a14890b2a3fa3b5db5820e17deb6 is the first bad commit commit da0784f961d8a14890b2a3fa3b5db5820e17deb6 Author: Jan Beulich Date: Wed Sep 27 14:16:09 2023 +0200 x86: fold FMA VEX and EVEX templates Following the folding of some generic AVX/AVX2 templates with their AVX512F counterpart ones, do this for FMA ones as well, requiring one further adjustment to cpu_flags_match(). gas/config/tc-i386.c |4 + opcodes/i386-opc.tbl | 41 +- opcodes/i386-tbl.h | 1662 +++--- 3 files changed, 520 insertions(+), 1187 deletions(-) bisect found first bad commit -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/27217] aarch64 as Internal error in md_apply_fix at ....../gas/config/tc-aarch64.c:8330.
https://sourceware.org/bugzilla/show_bug.cgi?id=27217 Pete Moore changed: What|Removed |Added CC||petemoore at gmx dot net --- Comment #30 from Pete Moore --- I have a simple test case which I think is consistent with this bug: ``` $ cat adrp.s .global _start _start: adrp x0, 0x8000 ``` After assembling and linking: ``` $ aarch64-none-elf-as -o adrp.o adrp.s $ aarch64-none-elf-ld -Ttext=0x0 -o adrp.elf adrp.o aarch64-none-elf-ld: adrp.o: in function `_start': (.text+0x0): undefined reference to `no symbol' ``` Note, the following trick works (if e.g. _start is known to be 0): ``` $ cat adrp.s .global _start _start: adrp x0, 0x8000 + _start ``` which assembles as desired: ``` $ aarch64-none-elf-objdump -d adrp.elf adrp.elf: file format elf64-littleaarch64 Disassembly of section .text: <_start>: 0: 9040adrpx0, 8000 <_start+0x8000> ``` However, this only works if _start is fixed and known. Being able to specify an absolute (rather than relative) value for the immediate of the adrp instruction is useful for e.g. referencing peripherals at fixed locations which are known to be in the +/- 4GB range of the current address. My particular use case is referencing Raspberry Pi peripheral base addresses. Let me know if I should raise a separate bug, or if the above test case is is consistent with the current bug. Many thanks! ``` $ aarch64-none-elf-ld --version GNU ld (GNU Binutils) 2.39 ``` -- You are receiving this mail because: You are on the CC list for the bug.
