x86-64

I'm trying to implement an algorithm in assembly (MASM64, Windows, x64) using jump tables. Basic idea is: there are 3 different types of operations I need to do with data. The operations depend on some variables, but I found it tedious to implement a lot of switching and many long implementations. PUBLIC superFunc@@40 ;__vectorcall decoration .DATA ALIGN 16 jumpTable1 qword func_11, func_12, func_13, func_14 jumpTable2 qword func_21, func_22, func_23, func_24 jumpTable3 qword func_31, func_32, func_33, func_34 .CODE superFunc@@40 PROC ;no stack actions, as we should do our stuff as a leaf

I have an AMD processor of e2-2000 model. THis is family 0fh. According to family 0fh BKDG I have this code to read device and vendor ID: ReadPCIConfiguration: movq $0x80000100, %rax movq $0x0cf8, %rdx outl %eax, %dx # sigsegv caught here movq $0x0cfc, %rdx inl %dx, %eax ret As far as I know the algorithm to read/write PCI configuration is as follows: write target bus number, device number function number and offset or register number to configuration address port perform 1-, 2- or 4-byte r/w operation from/to configuration data port Ports 0xcf8..0xcfb - configuration address port (doubleword)

I have been browsing for a while and I am trying to understand how memory is allocated to the stack when doing for example: push rax Or moving the stack pointer to allocate space for local variables of a subroutine: sub rsp, X ;Move stack pointer down by X bytes What I understand is that the stack segment is anonymous in the virtual memory space,i.e., not file backed. What I also understand is that the kernel will not actually map an anonymous virtual memory segment to physical memory until the program actually does something with that memory segment,i.e, write data. So, trying to read that

From android developer website, https://developer.android.com/distribute/best-practices/develop/64-bit it is clear that starting August 1, 2019, apps published on Google Play will need to support 64-bit architectures. Our current app has native libraries for armeabi-v7a, arm64-v8a, x86 ABIs but no x86-64. This is because one of the cordova plugins we are using doesn't provide X86-64 support. Will playstore reject the app update or pass it considering there is arm64-v8a support or we will have to drop support for x86 to stay compliant? tl;dr Unity Technologies' User ScottF (1) confirmed with

I'm using sys_brk syscall to dynamically allocate memory in the heap. I noticed that when acquiring the current break location I usually get value similar to this: mov rax, 0x0C mov rdi, 0x00 syscall results in rax 0x401000 The value usually 512 bytes aligned. So I would like to ask is there some alignment requirements on the break value? Or we can misalign it the way we want? The kernel does track the break with byte granularity. But don't use it directly for small allocations if you care at all about performance. There was some discussion in comments about the kernel rounding the break to a

I am currently following along with this tutorial , but I'm not a student of that school. GDB gives me a segmentation fault in thread_start on the line: movq %rsp, (%rdi) # save sp in old thread's tcb Here's additional info when I backtrace: #0 thread_start () at thread_start.s:16 #1 0x0000000180219e83 in _cygtls::remove(unsigned int)::__PRETTY_FUNCTION__ () from /usr/bin/cygwin1.dll #2 0x00000000ffffcc6b in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) Being a newbie, I can't for my life figure out why. Here is my main file: #define STACK_SIZE 1024*1024 //Thread

I am trying to write a simple program in assembly that will write out the name of the program. Using gdb to debug, I've determined that the call to sys_write is returning -14 (EFAULT). I've also been able to verify that my strlen function is working correctly. It seems like there is some sort of memory access issue, but I don't understand what could be wrong given that strlen is accessing the same memory and working fine. What is going wrong? Thanks! The full code: section .text global _start _start: mov rax, [rsp+8] push rax call strlen add rsp, 8 mov rdx, rax ; bytes to write mov rax, 4 ;

According to AMD manual segmentation can not be disabled. My question is why, why it's impossible? Another question, it says that 64-bit disables it, what does that mean? Is segmentation completly disabled on 64-bit mode? AMD Manual: https://s7.postimg.cc/hk15o6swr/Capture.png Introduction In 64-bit mode, whenever a non-null segment selector is loaded into any of the segment registers, the processor automatically loads the corresponding segment descriptor in the hidden part of the segment register, just like in protected/compatibility mode. However, the segment descriptors selected by the DS,

Local static objects in C++ are initialized once, the first time they are needed (which is relevant if the initialization has a side effect): void once() { static bool b = [] { std::cout << "hello" << std::endl; return true; } (); } once will print "hello" the first time it is called, but not if it is called again. I've put a few variations of this pattern into Compiler Explorer and noticed that all of the big-name implementations (GCC, Clang, ICC, VS) essentially do the same thing: a hidden variable guard variable for once()::b is created, and checked to see whether the primary variable needs