https://sourceware.org/bugzilla/show_bug.cgi?id=33524
Bug ID: 33524
Summary: `--oformat=binary` is inconsistent between targets
Product: binutils
Version: unspecified
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: mhilgy at gmail dot com
Target Milestone: ---
I notice that `--oformat=binary` does not work on aarch64, but does the right
thing on x86_64. Here's an example demonstrating the issue:
// start.s
.section .text.start,"ax",@progbits
.global _start
_start:
mov x29, xzr
mov x0, sp
bl main // exit(main())
mov x8, 93
svc #0
// main.c
int main () { return 42; }
// link.ld
SECTIONS
{
. = 0x0;
.text : {
*(.text.start)
*(.text)
}
.data : { *(.data) }
.bss : { *(.bss) }
}
I compile the object file input to ld like so:
gcc start.s -o start.o # some other flags controlling generated code
gcc main.c -o main.o # ...
# Now I want to link the object code:
ld start.o main.o -T link.ld --oformat=binary
On x86_64 (assuming that I use the appropriate assembly) this gives me exactly
what I want: a file containing just the compiled object code from one loadable
segment where the 0th byte contains the first instruction of _start.s. I can
load this with mmap, jump to the entrypoint, and the program runs.
On aarch64 I get an error:
/usr/bin/ld: a.out: can not make object file: invalid operation
A workaround is to use `objcopy -O binary`, however this doesn't give me what I
was expecting - the binary output contains the single loadable segment
including the elf header and program header table with the first instruction
offset.
>From reading other bug reports, it's not clear to me if this is intended
behavior, WONTFIX, or an outright bug in `ld`. The command works as intended on
one arch but errors on another, while other linkers (gold and lld) seem to do
the right thing.
I understand --oformat=binary is not intended as a general purpose command -
I'm using it to essentially strip all the ELF metadata out from freestanding
binaries so they can be used in isolation.
- Mike Hilgendorf
--
You are receiving this mail because:
You are on the CC list for the bug.
