I'v been trying to assemble and link some x86_64 assembler using llvm-mc (13.0.1) and lld (13.0.1) on macos (12.5). I'm using the following procedure to assemble and link:
llvm-mc --filetype=obj -g -o test.o test.s
ld64.lld -arch x86_64 -platform_version macos 12.0.0 12.0.0 -e start -o test test.o
Today I got an error that I don't understand:
ld64.lld: error: BRANCH relocation has width 1 bytes, but must be 4 bytes at offset 1 of __TEXT,__text in test.o
I couldn't find an explanation of this error. Google tells me nothing, and I couldn't find the error by searching the llvm source.
Figuring it has something to do with jumps, I commented out code until the error went away, then worked backwards to make a minimum example showing the issue:
.text
.globl start
start:
main:
endloop:
loop main
The key detail is the endloop label between the loop instruction and the label main to which we are looping. If I comment out the main: label, I don't get the error.
Questions:
Anybody know what this error message means?
How can I fix the issue?
Where are the error messages for llvm's lld documented?
Related
I would like to compile "Hello World" in Windows Subsystem for Linux (WLS) with Debian.
.text
.global _start
_start:
movl $len,%edx
movl $msg,%ecx
movl $1,%ebx
movl $4,%eax
int $0x80
movl $0,%ebx
movl $1,%eax
int $0x80
.data
msg:
.ascii "Hello, world!\n"
len = . - msg
If i compile in a Debian server with
gcc -nostdlib -o hello hello.s
It work, but in WLS return error
/usr/bin/ld: /tmp/cciVVddg.o: relocation R_X86_64_32 against `.data' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Nonrepresentable section on output collect2: error: ld returned 1 exit status
I also tried
gcc -fPIC -nostdlib -o hello hello.s
There are two problems with your code:
your code is intended to be 32 bit code but gcc tries to assemble it as 64 bit code. You can fix this by passing -m32 in all stages of assembly and linkage. Please keep in mind that WSL does not actually support 32 bit code so you won't be able to run your program even if you manage to assemble it.
gcc tries to generate a position-indepentent executable. To make your code work in such an executable, you need to write position indepentent code. To do so, you need to avoid any absolute references to the addresses of variables. In 32 bit code, this is a bit tricky and I'm not going to explain this further as 32 bit code won't run on WSL anyway. The compiler advises you to compile with -fpic because that causes the compiler to generate position independent code from C files, but for assembly files it's ineffective. You can fix this issue by linking with -no-pie, causing the linker to generate a normal position-dependent binary. Note that this still doesn't mean that a 32 bit binary is going to run in WSL.
This is an issue that didn't used to ever occur. I'm pretty convinced it's probably an issue with my package repos (I recently reinstalled my Arch system and this has only just started happening).
I wrote a small hello world in x86_64:
.data
str: .asciz "Test"
.text
.globl main
main:
sub $8, %rsp
mov $str, %rdi
call puts
add $8, %rsp
ret
and then I attempt to assembly and link using GCC - like I have done many times in the past - with, simply:
gcc test.s -o test
and then this error is outputted:
/usr/bin/ld: /tmp/ccAKVV4D.o: relocation R_X86_64_32S against `.data' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
This error has never occured for me ever. I've tried to fix the issue by googling the same error message but it comes up with things that are so specific whereas I'd consider this a general issue. I've tried reinstalling base-devel and the entire GCC toolchain. I dunno what else I can do (please don't suggest using nasm, that's heresy).
I'd like to think I'm missing something obvious but I've used GCC for my assembly needs for a long time.
The way to get around this error is to generate a no-pie (Non Position Independent executable) executable :
gcc -no-pie test.s -o test
The reason for this behaviour is as explained by #Ped7g :
Debian switched to PIC/PIE binaries in 64-bits mode & GCC in your case is trying to link your object as PIC, but it will encounter absolute address in mov $str, %rdi.
Hi i am getting several errors while linking my ".s" file together.
First of all, i compile the file via "gcc -S -m32 search.c" to
get my 32-bit assembler code.
Secondly i want to link the program back together by using "gcc -o
search search.s"
If i do this i get the following error: "Error: invalid instruction suffix for `push." I tried to use google to solve the problem and found a solution by using the --32 option flag. But this did not work either. The following error shows up as an result:
usr/bin/ld: i386 architecture of input file is incompatible with i386:x86-64 output. The third option by adding .code32 to the .s file, gcc let me compile it. Though by executing the console immediately says "core dumped".
So i really do not know what to do now. Anyone has an idea how i get things working?
Cheers
Assemble with --32, and link with -m32.
gcc -m32 -o search search.s
Without -m32, the output is going to be a 64-bit executable. The error message is due to the input object being a 32-bit object; you can't produce a 64-bit executable from 32-bit objects.
I'm working on a snow leopard machine (10.6.5) and I'm hunting a bug in our C++ application. However, I can't build our app with g++ -O0 -g, because the linker crashes:
g++-4.0 -arch i386 -arch x86_64 ... -dynamic -bundle -o SOMELIB.dylib <SOME OBJECTS>...
collect2: ld terminated with signal 11 [Segmentation fault]
collect2: ld terminated with signal 11 [Segmentation fault]
I guess the two crashes are because there are two "-arch" flags.
I managed to get a core file, which said the crash occurs in
(gdb) bt
#0 0x000000010001a2eb in Linker::synthesizeDebugNotes ()
#1 0x0000000100024cc5 in Linker::collectDebugInfo ()
#2 0x0000000100028198 in Linker::link ()
#3 0x000000010002a9eb in main ()
With this hint, I removed '-g' from the compiler flags, and everything builds fine. Moreover, most of our stuff builds fine with '-g', but just two of the big modules (.dylibs) don't, so I'm left with no debuginfo for those. And, ironically, the bug lurks just there, in one of these dylibs.
The bug is most likely due to an uninitialized memory use, as it manifests rarely, and running the app under valgrind reveals that there are a few uninitialized memory refences, but because of the missing debuginfo, it just says it happens inside module XXX (the dylib I can't compile with "-g")
So, I tried to download the ld utility from Apple's open source website, but I found (just like that guy) that it won't build because of a missing dependency to a Mac-specific version of libunwind, which Apple won't give away. Thus I can't recompile the linker.
So the next question is - what should I do now? I really wanted to avoid contacting Mac support...
ld version is "ld64 97.17", XCode is 3.2.5, gcc is 4.0.1.
I really need some directions...
I have the following program:
~/test> cat test.cc
int main()
{
int i = 3;
int j = __sync_add_and_fetch(&i, 1);
return 0;
}
I'm compiling this program using GCC 4.2.2 on Linux running on a multi-cpu 64-bit Intel machine:
~/test> uname --all
Linux doom 2.6.9-67.ELsmp #1 SMP Wed Nov 7 13:56:44 EST 2007 x86_64 x86_64 x86_64 GNU/Linux
When I compile the program in 64-bit mode, it compiles and links fine:
~/test> /share/tools/gcc-4.2.2/bin/g++ test.cc
~/test>
When I compile it in 32-bit mode, I get the following error:
~/test> /share/tools/gcc-4.2.2/bin/g++ -m32 test.cc
/tmp/ccEVHGkB.o(.text+0x27): In function `main':
: undefined reference to `__sync_add_and_fetch_4'
collect2: ld returned 1 exit status
~/test>
Although I will never actually run on a 32-bit processor, I do need a 32-bit executable so I can link with some 32-bit libraries.
My 2 questions are:
Why do I get a link error when I compile in 32-bit mode?
Is there some way to get the program to compile and link, while still being able to link with a 32-bit library?
The answer from Dan Udey was close, close enough in fact to allow me to find the real solution.
According to the man page "-mcpu" is a deprecated synonym for "-mtune" and just means "optimize for a particular CPU (but still run on older CPUs, albeit less optimal)". I tried this, and it did not solve the issue.
However, "-march=" means "generate code for a particular CPU (and don't run on older CPUs)". When I tried this it solved the problem: specifying a CPU of i486 or better got rid of the link error.
~/test> /share/tools/gcc-4.2.2/bin/g++ -m32 test.cc
/tmp/ccYnYLj6.o(.text+0x27): In function `main':
: undefined reference to `__sync_add_and_fetch_4'
collect2: ld returned 1 exit status
~/test> /share/tools/gcc-4.2.2/bin/g++ -m32 -march=i386 test.cc
/tmp/ccOr3ww8.o(.text+0x22): In function `main':
: undefined reference to `__sync_add_and_fetch_4'
collect2: ld returned 1 exit status
~/test> /share/tools/gcc-4.2.2/bin/g++ -m32 -march=i486 test.cc
~/test> /share/tools/gcc-4.2.2/bin/g++ -m32 -march=pentium test.cc
From the GCC page on Atomic Builtins:
Not all operations are supported by
all target processors. If a particular
operation cannot be implemented on the
target processor, a warning will be
generated and a call an external
function will be generated. The
external function will carry the same
name as the builtin, with an
additional suffix `_n' where n is the
size of the data type.
Judging from your compiler output, which refers to __sync_add_and_fetch_4, this is what's happening. For some reason, GCC is not generating the external function properly.
This is likely why you're only getting an error in 32-bit mode - when compiling for 64-bit mode, it compiles for your processor more closely. When compiling for 32-bit, it may well be using a generic arch (i386, for example) which does not natively support those features. Try specifying a specific architecture for your chip family (Xeon, Core 2, etc.) via -mcpu and see if that works.
If not, you'll have to figure out why GCC isn't including the appropriate function that it should be generating.