I’m experimenting with running 32-bit code inside a 64-bit Linux process. The 32-bit code is completely self-contained, it makes direct IA32 system calls on its own. If I were to load this code in a 32-bit process, it would run just fine. Initially, I thought I could just allocate a stack for the 32-bit code, switch to it and everything
Tag: x86-64
SSE: unaligned load and store that crosses page boundary
I read somewhere that before performing unaligned load or store next to page boundary (e.g. using _mm_loadu_si128 / _mm_storeu_si128 intrinsics), code should first check if whole vector (in this case 16 bytes) belongs to the same page, and switch to non-vector instructions if not. I understand that this is needed to prevent coredump if next page does not belong to
How can gcc/clang assume a string constant’s address is 32-bit?
If I compile this program: for x86-64, the asm output uses movl $.LC0, %edi / call puts. (See full asm output / compile options on godbolt.) My question is: How can GCC know that the the string’s address can fit in a 32bit immediate operand? Why doesn’t it need to use movabs $.LC0, %rdi (i.e. a mov r64, imm64, not
Calling Assembly code from C++
I’m trying to write my own I/O library, so the first step is just being able to output a character. So far, this only needs to work on Linux. I wrote what I believe to be a solid _putc: label in x86 (with Intel syntax), and I put it in “io.h”, then called it from my main file, “test.cpp”. Here’s
Difference in behaviour between code executed by a pthread and the main thread in x64-assembly
When writing some x64 assembly, I stumbled upon something weird. A function call works fine when executed on a main thread, but causes a segmentation fault when executed as a pthread. At first I thought I was invalidating the stack, as it only segfaults on the second call, but this does not match with the fact that it works properly
Why doesn’t the ‘syscall’ instruction work under Linux?
I have a very basic assembly program that runs in Linux userland: However, this doesn’t work as it is, but only if I replace the syscalls with int 0x80. Don’t these do the same thing? I know that syscall was designed to be lower-latency, but other than that, I didn’t think there was a difference. Why doesn’t it work? Answer
Why malloc is faster than static memory allocation in my test program?
I have a test program. I get this result when executing it in ubuntu trusty 64 bit. malloc time:9571 static time:45587 Why malloc is faster than static memory allocation,or my test program is wrong? The test program is like this. Answer That benchmark is essentially meaningless because most of what it is measuring has little relationship with the use of
Function arguments in x86-64 asm
So I have to do this project for school that consists of reading a file in brainfuck and interpret it as assembly. The code works if I save the file path as a String inside the .data section, but what I want to have it so it gets the file path as an argument when starting the code in the
assembly function segfault at return (nasm x64)
My asm function segfaults at return. Here is the function prototype : void ft_cat(int fd); Basically it get a fd from a C main and act like cat shell command. I get no problem if I removed read and write parts so maybe the problem is around syscalls. I just can’t tell. I already spent hours and hours looking for
pthread_detach() causes SIGSEGV on 64 bit Linux
Here is a description of my situation: I have to take care of the bug in our product. The thread is created as joinable , it must do its work, terminate and nobody will call pthread_join() for it. So the thread is created with JOINABLE attribute (by default) and before termination it calls the next code: It works like a