x86-64

问题 For testing LD_PRELOAD, I wrote my own getpid , which prints something before calling the original getpid using dlsym. The code is given below. #define _GNU_SOURCE #include <unistd.h> #include <stdio.h> #include <dlfcn.h> typedef pid_t (*getpidType)(void); pid_t getpid(void) { printf("Hello, getpid!\n"); getpidType f = (getpidType)dlsym(RTLD_NEXT, "getpid"); return f(); } However when I use such getpid in my program and run it using LD_PRELOAD, by typing LD_PRELOAD=./prelib.so ./prog , I get

问题 I'm writing some x86_64 assembly to call a C function. My C function takes in 1 argument, so the assembly places the argument in %rdi . The ABI pdf (linked below) says that the other 6 argument registers (rsi, rdx, rcx, r8, r9) are not preserved across function calls. However, since my C function only takes one long argument, do I have any guarantees about whether or not the C function will clobber the other 5 registers? My assumption was that the argument registers are only clobbered if an

问题 Sometimes I use the following code to avoid stack overflow when taking part in coding competition. int main() { static const int _STACK_SIZE = MAXN*10; static int _STACK[_STACK_SIZE*2], _ESP; __asm__ __volatile__ ( "movl %%esp, %0\n" "movl %1, %%esp\n": "=g"(_ESP): "g"(_STACK + _STACK_SIZE): ); // Do Something.. __asm__ __volatile__ ( "movl %0, %%esp\n": : "g"(_ESP): ); } As far as I know, this asm code backups %esp and moves the stack to _STACK[] . My Question: Why this code cause SIGSEGV on

问题 I'm trying to build a gcc multilib tool chain on AMD64 version of fresh ubuntu 14.04 installation. It only has a x86_64 gcc and g++ installation without multilib support. My configuration line is ../configure --disable-checking --enable-languages=c,c++ --enable-multiarch --enable-multilib --enable-shared --enable-threads=posix --with-system-zlib When I make it fails somewhere around building 32bit libgcc complaining about a missing sys/cdefs.h I can't post a build log right now but the error

问题 While reading the Intel 64 and IA-32 Architectures Software Developer’s Manual, the operation section for the LEA instruction (load effective address) uses a calculation called EffectiveAddress(SRC) which is not defined anywhere else. What is the definition of effective address and what does EffectiveAddress(SRC) do? 回答1: Section 3.7.5 (Specifying an Offset) of the same document states: The offset part of a memory address can be specified directly as a static value (called a displacement) or

问题 I have three projects, ProjectA (exe) , ProjectB (exe) and ProjectD (class library) Project A references the System.Data.OracleClient.dll and ProjectD. Project B just references ProjectD. The 32-bit client version of oracle is installed and therefore ProjectA has to be a 32-bit application. Project B can be built as a 64-bit application. Project A build settings: Platform: Active (x86) Platform target: x86 Project B build settings: Platform: Active (Any CPU) Platform target: Any CPU My

问题 I am trying to link a static library that I created, but I get this error. libmine.a: could not read symbols: Archive has no index; run ranlib to add one I tried to do ranlib libmine.a but nothing changed, it still gives the same error. How can I solve this problem? 回答1: To see the symbols in an archive, use nm. nm -s libmine.a <output> The entry points to the subroutines should be labled "T" as in 00000000 T _sub1 00000019 T _sub2 What switches did you use in "ar" to make the static library?

问题 Do different sections of libc (such as .text , .plt , .got , .bss , .rodata , and others) get loaded at the same offset relative to the libc base address every time? I know the loader loads libc at a random location every time I run my program. Thank you in advance. 回答1: I guess I found the answer to my own question. I wrote a pin-tool using Intel PIN that on every libc section get loaded outputs the section offset relative to the address of libc . Here are the sections having get loaded at

问题 This function aims to get the start address of the stack: unsigned long find_start(void){ __asm__("movq %rsp, %eax"); } When I compile it,getting an error: Error: suffix or operands invalid for `movq' 回答1: movq is an instruction that expects 64-bit operands. rsp is a 64-bit register, while eax is a 32-bit register. Perhaps try rax ? 回答2: %eax is the 32-bit GP register. However you are trying to do a 64-bit move with it. It should be %rax . 回答3: You need, as stated, to use the 64-bit register

问题 In a comment to this question, Unexpected behaviour in simple pointer arithmetics in kernel space C code, Michael Petch wrote, "The 64-bit ELF format supports 32-bit code sections." I have a working program that includes both 32- and 64-bit code and switches between them. I have never been able to figure out how to link compiler-generated 32- and 64-bit code together without a linker error, so all the 32-bit code is written in assembly. As the project has become more complex, maintenance of