x86-64

问题 Could you describe the meanings and the differences between WC and WB memory on x86_64? For completeness, please, describe other types of memory on x86_64, if any. 回答1: I will first start with Writeback caching (WB) since it is easier to understand. Writeback caching As the name implies this caching strategy tries to delay the writes to the system memory as long as possible. The idea is to use only the cache, ideally. However, since the cache has a finite size smaller than the finite size of

问题 Could you describe the meanings and the differences between WC and WB memory on x86_64? For completeness, please, describe other types of memory on x86_64, if any. 回答1: I will first start with Writeback caching (WB) since it is easier to understand. Writeback caching As the name implies this caching strategy tries to delay the writes to the system memory as long as possible. The idea is to use only the cache, ideally. However, since the cache has a finite size smaller than the finite size of

问题 I know that the dynamic linker uses mmap() to load libraries. I guess it is the kernel who loads both the executable and its .interp reter into the same address space, but how does it determine where? I noticed that ld.so 's load address with ASLR disabled is 0x555555554000 (on x86_64) — where does this address come from? I tried following do_execve() 's code path, but it is too ramified for me not to be confused as hell. 回答1: Read more about ELF, in particular elf(5), and about the execve(2)

问题 Lets say, you have an application, which is consuming up all the computational power. Now you want to do some other necessary work. Is there any way on Linux, to interrupt that application and checkpoint its state, so that later on it could be resumed from the state it was interrupted? Especially I am interested in a way, where the application could be stopped and restarted on another machine. Is that possible too? 回答1: In general terms, checkpointing a process is not entirely possible

问题 my problem with vsprintf is that I can not obtain input arguments directly, I have to first get inputs one by one and save them in void** , then pass this void** to vsprintf() , it is all fine for windows, but when I come to 64bit linux, gcc cannot compile because it is not allowed to convert from void** to va_list , Is there anyone that can give me some help how I should do this under linux? Can I create va_list dynamically in GCC? void getInputArgs(char* str, char* format, ...) { va_list

问题 I'm a CS student writing in Intel x86-64 assembly, compiling with nasm , and running on an Core i7 processor with Ubuntu 12.04 as the guest OS. Does anyone have an example of how to use XSAVE and XRSTOR ? I've read the section on XSAVE in Intel Architectures Software Developers manual several times. I tried to implement xsave in C++ and then disassemble the binary to get an understanding of what it's doing. And of course I've scoured the Internet for examples. Any suggestions would be much

问题 I was reading the following definition for syscall: .text .globl syscall .type syscall,%function .align 16 syscall: movq %rdi, %rax /* Syscall number -> rax. */ movq %rsi, %rdi /* shift arg1 - arg5. */ movq %rdx, %rsi movq %rcx, %rdx movq %r8, %r10 movq %r9, %r8 movq 8(%rsp),%r9 /* arg6 is on the stack. */ syscall /* Do the system call. */ cmpq $-4095, %rax /* Check %rax for error. */ jae __syscall_error /* Branch forward if it failed. */ ret /* Return to caller. */ .size syscall,.-syscall I

问题 Closed. This question is off-topic. It is not currently accepting answers. Want to improve this question? Update the question so it's on-topic for Stack Overflow. Closed 7 years ago . x86/x86-64 exposes MTRR (Memory-type-range-register) that can be useful to designate different portions of physical address space for different usages (e.g., Cacheable, Unchangeable, Writecombining, etc.). My question is is anybody knows how these constrained on physical address space as defined by the MTRRs are

问题 Apparently MSVC++2017 toolset v141 (x64 Release configuration) doesn't use FYL2X x86_64 assembly instruction via a C/C++ intrinsic, but rather C++ log() or log2() usages result in a real call to a long function which seems to implement an approximation of logarithm (without using FYL2X ). The performance I measured is also strange: log() (natural logarithm) is 1.7667 times faster than log2() (base 2 logarithm), even though base 2 logarithm should be easier for the processor because it stores

问题 I'm trying to make a small program in assembly (for AT&T). I'm trying to get an input from the user in the form of an integer, increment it after that and then output the incremented value. However, the value doesn't increment. I've spent the last hours trying everything I could come up with, but it still doesn't work, so I have the idea that I maybe understand a concept in assembly not well, causing me to not spot the mistake. This is my code: 1 hiString: .asciz "Hi\n" 2 formatstr: .asciz "