When I compiled a program I was writing in C++ (for the latest Macbook pro, which of course supports the AVX instruction set), I got the following errors. I am using the latest release of g++ obtained from Macports. Do you have any ideas as to what I can do to fix the error without restricting the instruction sets available to the compiler? Is there any package in particular that I should try to update?
g++-mp-4.7 -std=c++11 -Wall -Ofast -march=native -fno-rtti src/raw_to_json.cpp -o bin/raw_to_json.bin
/var/folders/83/tjczqmxn1y9166m642_rxdlw0000gn/T//cc0hIx0w.s:1831:no such instruction: `vpxor %xmm0, %xmm0,%xmm0'
/var/folders/83/tjczqmxn1y9166m642_rxdlw0000gn/T//cc0hIx0w.s:1847:no such instruction: `vmovdqa %xmm0, 96(%rsp)'
/var/folders/83/tjczqmxn1y9166m642_rxdlw0000gn/T//cc0hIx0w.s:1848:no such instruction: `vmovdqa %xmm0, 112(%rsp)'
/var/folders/83/tjczqmxn1y9166m642_rxdlw0000gn/T//cc0hIx0w.s:1849:no such instruction: `vmovdqa %xmm0, 128(%rsp)'
/var/folders/83/tjczqmxn1y9166m642_rxdlw0000gn/T//cc0hIx0w.s:1850:no such instruction: `vmovdqa %xmm0, 144(%rsp)'
/var/folders/83/tjczqmxn1y9166m642_rxdlw0000gn/T//cc0hIx0w.s:1851:no such instruction: `vmovdqa %xmm0, 160(%rsp)'
Thanks for the help!
A simpler solution that fixed this problem for me was adding -Wa,-q to the compiler flags. From the man pages for as (version 1.38):
-q
Use the clang(1) integrated assembler instead of the GNU based system assembler.
Fixed thanks to Conrado PLG's answer to his own question here. In short, I had to do the following:
Move or otherwise get rid of the old as, found at /opt/local/bin/../local/libexec/as/x86_64/as.
Copy the script by Vincent Habchi, found here, to /opt/local/bin/../local/libexec/as/x86_64/as.
sudo chmod +x the script.
Note that there may some performance degradation, due to the fact that calling the assembler requires going through a shell script first.
Related
I want to play a bit with assembly. To get started I've created a little asm script and tried to compile it. In the first step everything went great:
nasm -felf64 hello.asm
But when I tried to use
ld -o hello.o hello
from MinGW an error occured:
hello.o: file not recognized: File format not recognized
What can I do to fix this problem? I've tried it with gcc as well but then the same error plus one other error occurs.
MinGW creates binaries targeting Windows. Windows does not support ELF binaries (or does it? with Windows subsystem for Linux?). Anyway, ld in MinGW will expect that you provide binaries in win64 format not elf64.
nasm -fwin64 hello.asm will most likely work.
No it won't work because I just saw your code, and you are using Linux syscalls under Windows.
Write,
mov rcx, 69
call ExitProcess
instead of,
mov rax, SYS_EXIT
mov rdi, 69
syscall
Leave a comment if it doesn't work.
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.
If I try to assemble this program:
.text
main:
andseq r1,r3,r2,lsl #13
With the command gcc -c test.s, I get the following error:
Error: bad instruction `andseq r1,r3,r2,lsl#13'
After some tries I replaced andseq with andeqs, and now it compiles fine.
But if I dump the resulting obj file with objdump -d test.o I get this:
Disassembly of section .text:
00000000 <main>:
0: 00131682 andseq r1, r3, r2, lsl #13
Note how the instruction is decoded as andseq ....
Am I missing something? Is this a bug?
My system is Raspbian GNU/Linux 8, and my gcc is: gcc (Raspbian 4.9.2-10) 4.9.2. I have also tested with gcc-8.1.0 (edit, not really see edit), same results.
EDIT:
In fact, it seems Im using the same binutils with gcc8, so I really only tested this GNU assembler (GNU Binutils for Raspbian) 2.25. I'll try a more recent assembler.
For compatibility with old assembly files, GNU as defaults to divided syntax for ARM assembly. In divided syntax, andeqs is the correct mnemonic for the instruction you desire. You can issue a .syntax unified directive to select unified syntax, in which andseq is the correct mnemonic.
GNU objdump on the other hand only knows unified syntax, which explains the apparent inconsistency.
For new developments, I advise you to consistently use unified syntax if possible.
There is a good UAL vs pre-UAL mnemonic table on ARMv8 Appendix K6 "Legacy Instruction Syntax for AArch32 Instruction Sets"
One of the entries of that table is:
Pre-UAL syntax UAL equivalent
AND<c>S ANDS<c>
where eq is one of the possible condition codes <c>.
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.
This is possibly similar to a question here: What's the purpose of the UD2 opcode in the Linux kernel?, however, I'm getting this on OSX not on linux, and wouldn't know where to look to see if it is the same as the BUG() macro mentioned there.
I've been getting a number of release build only crashes on my OSX build which are to do with the ud2 opcode and was wondering what would cause clang to generate them. Here is an example:
COMMON_UI::BackProject3DPosition(UTILITYLIB::TVECTOR<float, 3u> const&, UTILITYLIB::TVECTOR<float, 3u> const&) const:
0x1e0705c: pushl %ebp
0x1e0705d: movl %esp, %ebp
0x1e0705f: ud2
0x1e07061: nop
This only happens at -O2, and not -O1, so it looks like the optimisations are going slighty awry.
Any help would be greatly appreciated.
I'm not 100% sure about clang, but gcc sometimes inserts ud2 to mark code areas which exhibit undefined behavior and thus are not supposed to be executed. It does give a warning in such cases, however.
So I suspect there are some warning from the compiler which you are ignoring or suppressing. Try adding -Wall -Werror to the command line.