0

I'm trying to move the value in rax to the label I created. Essentially I'm trying to figure out what I should add to mov label, rax to make it work. Currently my label is declared as a quadword, but that can change. So far I've tried:

mov [label], rax - This compiles, but when I go to link it gives me a "Relocation truncated to fit error"

movq [label], rax - this will not compile

movq label, rax - this will also not compile

mov [label], [rax] - will not compile.

The ones that won't compile give me "invalid combination of opcode and operands". What am I supposed to do?

EDIT: fuz answered it in the comments. 'mov [rel label], rax' works. Thank you!

Smilez221
  • 27
  • 1
  • 1
  • 7
  • 1
    Try `mov [rel label], rax`. – fuz Oct 23 '19 at 19:34
  • 2
    The devil is in the details. Include your code, then it will probably become more evident for anyone attempting to help. – Shift_Left Oct 23 '19 at 19:34
  • What storage does `label` point to? (must be qword at least) – David C. Rankin Oct 23 '19 at 19:44
  • You can use `default rel` if you don't feel like writing `rel` all the time. – fuz Oct 23 '19 at 20:46
  • @Shift_Left: Yes in general a better [mcve] would be good, but I can tell from the "Relocation truncated to fit error" that they're trying to link on Linux with a gcc configured with default-pie. (Or some other platform where the linker gives the same error message for 32-bit absolute relocations). I think on MacOS it wouldn't have assembled in the first place (not representable in the MachO object file). Windows has a largeaddressaware flag that you can use to link executables to ASLR in the low 32 bits, although it's probably off by default so you'd get a similar error. – Peter Cordes Oct 23 '19 at 21:54
  • @PeterCordes That level of detail is beyond the scope of my experience and the only time I've encountered that is when I've attempted to write a 32 bit value into a 16 bit register. It is for that reason I didn't blurt out a solution as there just wasn't enough information. – Shift_Left Oct 23 '19 at 22:06
  • @Shift_Left: My point was that with the right experience / expertise, this does happen to be enough information, even though it doesn't look that way. In your case your "value" was probably a symbol address like `mov ax, label`? Yeah that would require truncating a relocation on linking into an executable when it turned out to be outside the low 16 bits. – Peter Cordes Oct 23 '19 at 22:18

1 Answers1

0
extern printf

section .data
    output db "%lld",10,0

section .bss
    num1: resq 1

section .text
    global main

main:
    push rbp

    mov rax, 666
    mov [num1], rax

    xor rax, rax
    mov rdi, output
    mov rsi, [num1]
    call printf

    pop rbp
    xor rax, rax
    ret

Compile and linking:

$ nasm -felf64 main.s && gcc -no-pie main.o

$ ./a.out

666

Community
  • 1
  • 1
  • 1
    That requires `-no-pie`. Also try explaining what you changed to solve OPs problem. – fuz Oct 23 '19 at 20:45
  • Why would you want 32-bit absolute `[disp32]` addressing modes instead of using `default rel` for RIP-relative? You only want `[disp32 + reg]` or scaled index for indexing a static array, not for a bare label. [32-bit absolute addresses no longer allowed in x86-64 Linux?](//stackoverflow.com/q/43367427). This works but it's *not* a good recommendation. There are many ways to do things in asm and this is one strictly worse than choices. (I'd be happy to change my downvote to an upvote if/when you improve this answer. Don't take it personally and welcome to Stack Overflow) – Peter Cordes Oct 23 '19 at 21:40