ELF64 code generation, memory addressing

Index > Main > ELF64 code generation, memory addressing

Author

Thread

Chewy509

Joined: 19 Jun 2003
Posts: 297
Location: Bris-vegas, Australia

Chewy509 30 May 2005, 02:03

Hi everyone,

I just would like to get some clarification on the code generation for ELF64 object files (*.o) and executables, in particular related to memory addressing.

While I understand that RIP addressing is used in x86-64 (aka AMD64), as IIRC absolute addresses are not possible (with a few small exceptions), I would assume that the following would work correctly, as FASM would generate the addresses correctly.

Code:

format ELF64
use64

public main
extrn gtk_main

section '.data' writeable

_DynNum rt 20 ; define 20 twords (or 80bit FP)

section '.text' executable

main:
    finit
    fld tword [_DynNum] ;load first element of array
    mov rax, rbx ;The element we want is in rbx
    push rax
    lea rax, [rax+rax*4] ; rax = rax * 5
    shl rax, 1 ; rax = rax * 2
    fld tword [rax+_DynNum] ;load element of array as defined by rbx
    pop rax

sys_exit:
    mov ebx,0 ;our exit code
    mov eax,1
    int 0x80

Which doesn't assemble with an error "address sizes do not agree" for the line fld tword [rax+_DynNum].

If however I turn this into an executable by changing the header to format ELF64 executable, remove the extrn reference and section lines, it assembles fine?

I would assume the difference is the way that the addresses are calculated based on whether the source is being assembled as an object file (*.o) or an executable.

So I have 3 questions?
1, How do I fix the first example to work?
2, As a clarifcation, if I use the "executable" flag am I generating a static linked ELF file, or a dynamic linked ELF file? And if dynamic linked, how do I tell the assembler what extrn's I am using in other files which will be linked at runtime?
3, Or this is a bug? (which is cool with me, as I completely understand the 64bit code generation is still considered alpha/beta).

--
Darran

PS. using FASM 1.61.8

30 May 2005, 02:03

UCM

Joined: 25 Feb 2005
Posts: 285
Location: Canada

UCM 31 May 2005, 00:55

By the way, 64bit code generation, as Privalov has mentioned many times, is not alpha/beta! It is quite stable. However, it still may be a bug, since bugs are not reliably avoidable.

31 May 2005, 00:55

Chewy509

Joined: 19 Jun 2003
Posts: 297
Location: Bris-vegas, Australia

Chewy509 31 May 2005, 01:14

RE: 64bit code generation beta status.

My understanding was, that until v1.64, 64bit code generation (while even in its current state is extremely stable and nearly complete) should be considered beta only. If I'm worng please let me know.

Thinking about this more, it does appear to be a bug.

This is my take on the issue, and needs Privalov to double check.

Since displacements in memory references are still limited to 32bit, (even in 64bit code generation), when FASM assembles ELF as executable it knows the correct offset to generate, and will correctly fit it into 32bits. However when assembling as an object file, it doesn't know the correct offset and wants to insert a 64bit space (which will get filled in by the linker), but since a displacement is limited to 32bit, you can't fit a 64bit value into a 32bit hole, and thus FASM generates an error.

If I'm wrong, then please let me know.

I also have another question, but in regards to uses pointers.

Say I have:

Code:

mov r10, _My_string
movzx r11, byte [r10]
movzx r12, byte [r10+1]

Will FASM load the absolute address of _My_String into r10, and the following loads use RIP relative or absolute addresses? (I'm still a little vague on where RIP addressing is used and not used).

31 May 2005, 01:14

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8353
Location: Kraków, Poland

Tomasz Grysztar 01 Jun 2005, 10:23

The features that are implemented in the stable releases (like 1.60, which implements the ELF64 output) are considered complete. The 1.64 release is planned as a "final" release for x86-64, because there are still Win64 formats left to be added (the COFF objects are already implemented for the coming 1.62), also maybe some Win64 includes, etc.

As for displacements, your explanation is correct - in case of object file fasm doesn't know whether the relocated address would fill in 32 bits and therefore doesn't allow absolute 32-bit addressing. The RIP-relative addressing is used by default, but since there is only RIP+imm32 addressing in x86-64 architecture, it cannot be used when there is any other register used in address. This is the limitation of x86-64 architecture and you have to take it into consideration when writing any code for the long mode.

01 Jun 2005, 10:23

Chewy509

Joined: 19 Jun 2003
Posts: 297
Location: Bris-vegas, Australia

Chewy509 01 Jun 2005, 23:28

Hi Privalov,

Thanks for clarifing the state of the 64bit code generation.

You indicated that all x86-64 address generation uses RIP addressing,

Quote:

The RIP-relative addressing is used by default

does that include addresses using registers as well, or does RIP only come into effect when only having an immediate as the address location? eg

Code:

movzx r10, byte [_my_byte]  ;Uses RIP addressing
movzx r10, byte [r0]        ;Uses absolute addressing becuase of register.

01 Jun 2005, 23:28

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8353
Location: Kraków, Poland

Tomasz Grysztar 02 Jun 2005, 06:05

The answer is already in my post above:

Quote:

(...) since there is only RIP+imm32 addressing in x86-64 architecture, it cannot be used when there is any other register used in address.

02 Jun 2005, 06:05

Chewy509

Joined: 19 Jun 2003
Posts: 297
Location: Bris-vegas, Australia

Chewy509 05 Jun 2005, 23:51

Thanks!

(Sorry, misread the post, and got a little confused Sad

)

05 Jun 2005, 23:51

fly

Joined: 27 Apr 2005
Posts: 11
Location: Salzburg, Austria

fly 06 Jun 2005, 14:26

i have a question regarding global variable addressing. the code below works fine if the "format ELF64 executable" is used, but produces a segfault if an elf object is generated and linked by using ld. i believe the relocation is responsible for that, but i do not know how that i can write to the variable in a other way...
please, can anybody help me?

Code:

format ELF64

public _start

section '.data' writeable

times 1951 db 0
variable dq 0

section '.text' executable
_start:
  mov [variable], rax
  int 3

        ret
;eof

06 Jun 2005, 14:26

scientica
Retired moderator

Joined: 16 Jun 2003
Posts: 689
Location: Linköping, Sweden

scientica 06 Jun 2005, 14:44

hmmm.. segevs for me too:

Code:

frekla@zeus /tmp $ fasm test.asm test.o
flat assembler  version 1.61.1
1 passes, 2485 bytes.
frekla@zeus /tmp $ ld test.o  -o test
frekla@zeus /tmp $ file test
test: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), statically linked, not stripped
frekla@zeus /tmp $ ./test
Segmenteringsfel

gdb says this:

Code:

(gdb) run

Program received signal SIGSEGV, Segmentation fault.
0x00000000004000e8 in _start ()

----------------

Dump of assembler code for function _start:
    0x00000000004000e8 <_start+0>:  mov    ds:0x798,rax
    0x00000000004000ef <_start+7>:  int    0x3
    0x00000000004000f1 <_start+9>:  ret    
End of assembler dump.

I have set gdb to use intel syntax, but I begin to wonder... (gdb is a bitch (im!ho))

06 Jun 2005, 14:44

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8353
Location: Kraków, Poland

Tomasz Grysztar 06 Jun 2005, 20:25

OK, finally found the bug that caused all those problems with ELF64 object - look out for 1.61.10 release, it's going to have it fixed.

06 Jun 2005, 20:25

< Last Thread | Next Thread >

Forum Rules:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum