x86-64

问题 I can not produce a "Bus error" with the following assembly code. Here the memory address I use is not a legal "canonical-address". So, how can I trigger that error? I was running this snippet of code under Ubuntu 20.04 LTS with NASM 2.14.02, but it results in a SIGSEGV segmentation fault on the load, not SIGBUS. global _start section .text _start: mov rax, [qword 0x11223344557788] mov rax, 60 xor rdi, rdi syscall Corresponding X86-64 assembly code after compiling: Disassembly of section

问题 I'm experimenting with sys_open syscall and I get file descriptor for reading. Here is my program: SYS_exit equ 0x3C SYS_open equ 0x02 O_RDONLY equ 0x00 O_WRONLY equ 0x01 O_RDWR equ 0x02 section .text global _start _start: mov eax, SYS_open mov rdi, file_name mov rsi, O_RDONLY mov rdx, 0x00 syscall mov eax, SYS_exit mov rdi, 0x00 syscall section .data file_name: db '/path/to/test\0' So when I ran strace ./bin I got the output: open("/path/to/test\\0", O_RDONLY) = -1 ENOENT (No such file or

问题 I'm experimenting with sys_open syscall and I get file descriptor for reading. Here is my program: SYS_exit equ 0x3C SYS_open equ 0x02 O_RDONLY equ 0x00 O_WRONLY equ 0x01 O_RDWR equ 0x02 section .text global _start _start: mov eax, SYS_open mov rdi, file_name mov rsi, O_RDONLY mov rdx, 0x00 syscall mov eax, SYS_exit mov rdi, 0x00 syscall section .data file_name: db '/path/to/test\0' So when I ran strace ./bin I got the output: open("/path/to/test\\0", O_RDONLY) = -1 ENOENT (No such file or

问题 My code: .section .data name: .string "/bin/sh" args: .string "-c" .string "ls" .section .text .globl _start _start: pushq $0 pushq name movq $59, %rax movq %rsp, %rdi pushq $0 pushq args movq %rsp, %rsi movq $0, %rdx syscall I know that the second argument of execve is array of chars. How to do this in assembly avoiding this: execve("./payload", ["./payload"], 0x7ffc291fd160 /* 40 vars */) = 0 execve("/bin/sh", [0x736c00632d], NULL) = -1 EFAULT (Bad address) --- SIGSEGV {si_signo=SIGSEGV, si

问题 On x86-64 CPUs (either Intel or AMD), is the "movnti" instruction that writes 4/8 bytes to a 32/64-bit aligned address atomic? 回答1: Yes, movnti is atomic on naturally-aligned addresses, just like all other naturally-aligned 8/16/32/64b stores (and loads) on x86. This applies regardless of memory-type (writeback, write-combining, uncacheable, etc.) See that link for the wording of the guarantees in Intel's x86 manual. Note that atomicity is separate from memory ordering. Normal x86 stores are

问题 Consider this code, from my earlier question. int main(){ asm("movq $100000000, %rcx;" "startofloop: ; " "sub $0x1, %rcx; " "jne startofloop; "); } I would like to make number of iterations of the loop a C variable, so I tried the following after reading this document. int main(){ int count = 100000000; asm("movq %0, %rcx;" "startofloop: ; " "sub $0x1, %rcx; " "jne startofloop; ":: "r"(count)); } Unfortunately, this fails to compile, and breaks with the following error. asm_fail.c: In

问题 In NASM assembly, there are db and dw pseudo instructions to declare data. NASM Manual provides a couple of examples but doesn't say directly what's the difference between them. I've tried the following "hello world" code with both of them, and it turned out that no difference is observable. I suspect the distinct has something to do with internal data format, but I don't know how to inspect that. section .data msg db "hello world",10,13,0 msg2 dw "hello world",10,13,0 section .text global

问题 Consider the following declaration of local variables: bool a{false}; bool b{false}; bool c{false}; bool d{false}; bool e{false}; bool f{false}; bool g{false}; bool h{false}; in x86-64 architectures, I'd expect the optimizer to reduce the initialization of those variables to something like mov qword ptr [rsp], 0 . But instead what I get with all the compilers (regardless of level of optimization) I've been able to try is some form of: mov byte ptr [rsp + 7], 0 mov byte ptr [rsp + 6], 0 mov

问题 Consider the following declaration of local variables: bool a{false}; bool b{false}; bool c{false}; bool d{false}; bool e{false}; bool f{false}; bool g{false}; bool h{false}; in x86-64 architectures, I'd expect the optimizer to reduce the initialization of those variables to something like mov qword ptr [rsp], 0 . But instead what I get with all the compilers (regardless of level of optimization) I've been able to try is some form of: mov byte ptr [rsp + 7], 0 mov byte ptr [rsp + 6], 0 mov

问题 When using persistent memory like Intel optane DCPMM, is it possible to see partial result after reboot if system crash(power outage) in execution of movnt instruction? For: 4 or 8 byte movnti which x86 guarantees atomic for other purposes? 16-byte SSE movntdq / movntps which aren't guaranteed atomic but which in practice probably are on CPUs supporting persistent memory. 32-byte AVX vmovntdq / vmovntps 64-byte AVX512 vmovntdq / vmovntps full-line stores bonus question: MOVDIR64B which has