[Bug binutils/32383] New: using objcopy on Mac OSX ARM64
https://sourceware.org/bugzilla/show_bug.cgi?id=32383 Bug ID: 32383 Summary: using objcopy on Mac OSX ARM64 Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: ralph.lessmann at hidglobal dot com Target Milestone: --- I am trying to use object copy to embed an segment into a library using the following command line: objcopy -B aarch64 -I binary -O mach-o-arm64 ./data.bin ./data.o The generated object file data.o cannot be used. When inspecting the file with objdump, I see the following mach-o header: architecture: aarch64, flags 0x0011: HAS_RELOC, HAS_SYMS start address 0x MACH-O header: magic: 0xfeedface cputype:0x10c (ARM64) cpusubtype: 0 (ARM64_ALL) filetype: 0x1 ncmds: 0x3 sizeocmds: 0xe4 flags: 0 version:1 It looks like the magic number and the version is wrong for mach-o-arm64. When I compare it with a linkable object file I got: architecture: aarch64, flags 0x0011: HAS_RELOC, HAS_SYMS start address 0x MACH-O header: magic: 0xfeedfacf cputype:0x10c (ARM64) cpusubtype: 0 (ARM64_ALL) filetype: 0x1 ncmds: 0x5 sizeocmds: 0x448 flags: 0x2000 version:2 And wikipidia tells: the magic number for 32-bit code is 0xfeedface while the magic number for 64-bit architectures is 0xfeedfacf I patched the objcopy source code for testing, but still beeing unable to link the generated object file. Not sure if this is a case of not supported or a bug. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/32374] gprofng: fails to build with GCC trunk (defaults to -std=gnu23)
https://sourceware.org/bugzilla/show_bug.cgi?id=32374
Vladimir Mezentsev changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #4 from Vladimir Mezentsev
---
I have a fix for these issues.
But I am not sure about the fix in gprofng/libcollector/dispatcher.c:
% git diff libcollector/dispatcher.c
diff --git a/gprofng/libcollector/dispatcher.c
b/gprofng/libcollector/dispatcher.c
index 4eda18ec324..240a090637f 100644
--- a/gprofng/libcollector/dispatcher.c
+++ b/gprofng/libcollector/dispatcher.c
@@ -1280,4 +1280,5 @@ __collector_ext_clone_pthread (int (*fn)(void *), void
*child_stack, int flags,
// weak symbols:
int sigprocmask (int, const sigset_t*, sigset_t*) __attribute__ ((weak, alias
("__collector_sigprocmask")));
int thr_sigsetmask (int, const sigset_t*, sigset_t*) __attribute__ ((weak,
alias ("__collector_thr_sigsetmask")));
-int setitimer () __attribute__ ((weak, alias ("_setitimer")));
+int setitimer (__itimer_which_t which, const struct itimerval *new_value,
+struct itimerval *old_value) __attribute__ ((weak, alias ("_setitimer")));
__itimer_which_t and setitimer are declared in /usr/include/sys/time.h on
Oracle Linux.
But I don't know if __itimer_which_t is defined on other Linuxes.
In man page, the first argument is 'int":
% man setitimer
SYNOPSIS
#include
int setitimer(int which, const struct itimerval *new_value,
struct itimerval *old_value);
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug gprofng/32373] gprofng: sysinfo interception needs porting to Linux from Solaris
https://sourceware.org/bugzilla/show_bug.cgi?id=32373 Vladimir Mezentsev changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #1 from Vladimir Mezentsev --- We don't use sysinfo. We can remove this code. But I see that we call libc functions directly (readlink, uname, maybe others). This needs to be fixed. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/32382] beq is misassembled
https://sourceware.org/bugzilla/show_bug.cgi?id=32382 H.J. Lu changed: What|Removed |Added Summary|as for RISC-V generates |beq is misassembled |gobbledygook with unusual | |but valid label formatting | Status|UNCONFIRMED |NEW Last reconfirmed||2024-11-21 Ever confirmed|0 |1 Version|2.43.1 |2.44 (HEAD) --- Comment #1 from H.J. Lu --- $ cat y.s beq t0, t1, 16 $ ./gas/as-new -o y.o y.s $ ./binutils/objdump -dwr y.o y.o: file format elf64-littleriscv Disassembly of section .text: <.text>: 0: 00629463bne t0,t1,8 <.text+0x8> 4: 006fj 4 <.text+0x4> 4: R_RISCV_JAL *ABS*+0x10 $ llvm-mc --triple=riscv64-linux --filetype=obj -o y.o y.s $ ./binutils/objdump -dwr y.o y.o: file format elf64-littleriscv Disassembly of section .text: <.text>: 0: 00628863beq t0,t1,10 <.text+0x10> $ -- You are receiving this mail because: You are on the CC list for the bug.
