address-size override with near calls in long mode
Intel manual (Vol.2 paragraph 126.96.36.199) says: The use of the address-size prefix does not disable RIP-relative addressing. The effect of the address-size prefix is to truncate and zero-extend the computed effective address to 32 bits. CALL rel32 description says: Call near, relative, displacement relative to next instruction. 32-bit displacement sign extended to 64-bits in 64-bit mode Thus, rel32 is immediate rather than address, as operand-size prefix overrides the default value. But if use address-size override prefix with near call (or jmp), will it zero-extend effective address as described above or it won't have any effect?
That isn't the type of RIP-relative addressing that a 67-prefix might target, a 67-prefix has no effect on call/jmp/jcc offsets (rather it is the 66-prefix that affects, for example, call rel16 vs call rel32). The type of RIP-relative addressing par 188.8.131.52 talks about is the sort of thing encoded by a ModRM byte that looks like 00***101, for example in something like mov rax, [eip] ; or, addr32 mov rax, [eip] ; or if your assembler doesn't let you write either of those, db 67 mov rax, [rip] this is one of the cases they meant, where rip-relative addressing is still active but truncated. If addressing reverted completely like how it is in 32bit mode, a ModRM like 00***101 would encode [sword] with no eip-involvement at all.
My kernel runs normally in qemu,but double fault in bochs
How can I get started on writing my own mobile OS for ARM processors?
Writing my own BIOS
Game in assembly language
stack frame size when I insert new instructions to assembly x86?
Mirroring Odd Bits of an Register
MIPS, assembly - a few questions
Can assembled ASM code result in more than a single possible way (except for offset values)?
NASM is pure assembly, but MASM is high level Assembly? [closed]
Neccessity of push and pop operands on CPUs
Compare two arguments ASM x64
treating command-line args as integers in x86 AT&T Assembly
Dll injection code
Can having an invalid stack pointer (even momentarily) cause you to lose data?
Searching an array using Assembly 8086
Code generation for an object