flat assembler
Message board for the users of flat assembler.

Index > Windows > Problem with commands in PE64 with .reloc section

Author
Thread Post new topic Reply to topic
Garthower



Joined: 21 Apr 2006
Posts: 158
Location: Ukraine
Garthower 05 Feb 2007, 01:10
I ahve a some DLL with code such:

Code:
format PE64 GUI DLL
.....
section '.code' code readable executable
.....
mov rdi,qword [@Params+rbx*8]
.....
section '.bss' data writeable
@Params         dq ?
.....
section '.reloc' fixups data discardable
    


And FASM 1.67.18 show a message "error: invalid size of address value". But if I delete reloc-section from the source all compile fine. Is I replace command "mov rdi,qword [@Params+rbx*8]" on "mov rdi,qword [@Params+rbx]" with .reloc rection all works fine too. I think this is a FASM bug... Certainly, I can break the given command into some other commands that all has earned, but it's not so convenient.
Post 05 Feb 2007, 01:10
View user's profile Send private message Visit poster's website MSN Messenger ICQ Number Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4623
Location: Argentina
LocoDelAssembly 05 Feb 2007, 01:42
Is the fixups really needed? Obviously are needed on 32-bit but on 64-bit I think that [@Params+rbx*8] is RIP-relative and for that reason it doesn't need relocation at all.

About the error probably happens because with the fixups you're forcing [offset_64_bits_wide+rbx*8] and x64 doesn't support such wider offsets.

[edit]Sorry, I'm wrong, it is not RIP-relative because there is a register in the addressing[/edit]
Post 05 Feb 2007, 01:42
View user's profile Send private message Reply with quote
Garthower



Joined: 21 Apr 2006
Posts: 158
Location: Ukraine
Garthower 05 Feb 2007, 01:58
LocoDelAssembly wrote:
Is the fixups really needed? Obviously are needed on 32-bit but on 64-bit I think that [@Params+rbx*8] is RIP-relative and for that reason it doesn't need relocation at all.


Yes, fixups really needed in DLL because DLLs are loaded to addresses different from Image Base in a PE-header. And all commands of direct addressing at generation of a code are leveled by Image Base.
Post 05 Feb 2007, 01:58
View user's profile Send private message Visit poster's website MSN Messenger ICQ Number Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4623
Location: Argentina
LocoDelAssembly 05 Feb 2007, 02:18
But the whole image doesn't get fragmented so if you have RIP-relative addressing then it doesn't matter the relocations, lea rsi, [@Params] should be transformed to lea rsi, [RIP+(@Params-$)]. At least that is what I understand by reading http://www.sandpile.org/aa64/opc_rm32.htm

Anyway, since you don't have any way to do [moffset64+any] you have to break that instruction.

I think that the bug is assembling fine that instruction just because @Params can be coded as a sdword when 64 bit relocations are not present or "(@Params shr 32) = 0".
Post 05 Feb 2007, 02:18
View user's profile Send private message Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4623
Location: Argentina
LocoDelAssembly 05 Feb 2007, 03:10
Here a demostration of the problem

Code:
; fasm demonstration of writing 64-bit ELF executable
; (thanks to František Gábriš)

; syscall numbers: /usr/src/linux/include/asm-x86_64/unistd.h
; parameters order:
; r9    ; 6th param
; r8    ; 5th param
; r10   ; 4th param
; rdx   ; 3rd param
; rsi   ; 2nd param
; rdi   ; 1st param
; eax   ; syscall_number
; syscall

; format ELF64 executable
format ELF64 executable at $100000000

segment readable executable

entry $

        mov     edx,msg_size    ; CPU zero extends 32-bit operation to 64-bit
                                ; we can use less bytes than in case mov rdx,...
        xor     rbx,rbx
        lea     rsi,[rbx+msg]
        mov     edi,1           ; STDOUT
        mov     eax,1           ; sys_write
        syscall

        xor     edi,edi         ; exit code 0
        mov     eax,60          ; sys_exit
        syscall

segment readable writeable

msg db 'Hello 64-bit world!',0xA
msg_size = $-msg    


At least with my debian with a 2.19 kernel the program no longer shows the "Hello 64-bit world!" message anymore but removing the "at $100000000" it shows the message again. I don't know if this is intended behavior but I dislike it very much, I think that it is quite wrong defaulting moffset as RIP-relative moffsets when there is no encoding for that.
Post 05 Feb 2007, 03:10
View user's profile Send private message Reply with quote
Garthower



Joined: 21 Apr 2006
Posts: 158
Location: Ukraine
Garthower 05 Feb 2007, 09:44
LocoDelAssembly wrote:
I think that the bug is assembling fine that instruction just because @Params can be coded as a sdword when 64 bit relocations are not present or "(@Params shr 32) = 0".


No, it's FASM's error. If to replace a command "mov rdi, qword [@Params+rbx*8]" on "mov rdi, qword [@Params+rbx]" and to leave reloc-section all it's compiled perfectly. Besides with MASM64 such problem does not arise on this example.

The example of demonstration of the given problem specified by you - just that is at me. Windows does not load DLL to the specified address from Image Base, in difference from Linux (as I have understood on your example). And the similar decision (to specify obviously Image Base by string "at $100000000") under Windows will not work.
Post 05 Feb 2007, 09:44
View user's profile Send private message Visit poster's website MSN Messenger ICQ Number Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8430
Location: Kraków, Poland
Tomasz Grysztar 05 Feb 2007, 10:07
The origins of this problem are explained here: http://board.flatassembler.net/topic.php?t=5458

Tomasz Grysztar wrote:
As for the 32-bit relocations with 64-bit code - it applies to object output, but not to the relocatable PE (in case when you include the fixups directory). It is possible to generate such relocation for the PE case, however such executable needs to be marked somehow that it can be run only in low 2 GB. As I wouldn't like to make programmer unaware of that he's forced his executable to be such because of some instruction like the one discusssed in this thread, there would have to be some explicit setting to make relocatable-in-low-2GB PE file. But as this seems to be not urgent thing, I will leave it as it is for now.


There are also some uninvestigated bugs in the recently reviewed symbol-type handling in 1.67.x, which may be related to the fact that it is sometimes assembled when it shouldn't. I'll look into this later today.
Post 05 Feb 2007, 10:07
View user's profile Send private message Visit poster's website Reply with quote
Garthower



Joined: 21 Apr 2006
Posts: 158
Location: Ukraine
Garthower 05 Feb 2007, 22:36
I apologize that has got a new thread. I have forgotten about old thread though I have created it Confused

But all is equal, I thought that it is new bug since the example resulted in an old thread is compiled fine.
Post 05 Feb 2007, 22:36
View user's profile Send private message Visit poster's website MSN Messenger ICQ Number Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4623
Location: Argentina
LocoDelAssembly 06 Feb 2007, 00:32
Since my XP64 isn't dead after all here a Windows example of the problem
Code:
format PE64 GUI 5.0 at $7fff0000
include 'win64a.inc'

        xor     rbx, rbx
        lea     rbx,[rbx+_message]

        invoke  MessageBox, 0, _caption, rbx, 0
        invoke  ExitProcess, 0

  _caption db 'Win64 assembly program',0
;  rb      $1000 ; Works with this one
  rb      $10000 ; Crashes the program
  _message db 'Hello World!',0

data import
  library kernel32,'KERNEL32.DLL',\
          user32,'USER32.DLL'

  include 'api\kernel32.inc'
  include 'api\user32.inc'
end data    
Post 06 Feb 2007, 00:32
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8430
Location: Kraków, Poland
Tomasz Grysztar 10 Feb 2007, 13:32
Corrected in 1.67.19.
Post 10 Feb 2007, 13:32
View user's profile Send private message Visit poster's website Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4623
Location: Argentina
LocoDelAssembly 10 Feb 2007, 14:33
My example above still crash.

[edit] For "lea rbx,[rbx+_message]" assembles "lea rbx, [rbx-$7FFFEFA3]" and for "lea rbx, [EBX+_message]" assembles "lea rbx, [ebx-$7FFFEFA2]" but works in with this Confused[/edit]

[edit2]Aaah, the second one works because of the zero extention?[/edit2]
Post 10 Feb 2007, 14:33
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8430
Location: Kraków, Poland
Tomasz Grysztar 10 Feb 2007, 15:58
This example is a different problem, the problem in this thread was with error checking in relocations handling, your PE is not relocatable and it's all just absolute values.
Post 10 Feb 2007, 15:58
View user's profile Send private message Visit poster's website Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4623
Location: Argentina
LocoDelAssembly 10 Feb 2007, 16:37
Oh, pardon Razz I thought that this problem was messing the relocations in some way.
Post 10 Feb 2007, 16:37
View user's profile Send private message Reply with quote
Garthower



Joined: 21 Apr 2006
Posts: 158
Location: Ukraine
Garthower 11 Feb 2007, 01:46
Whether and there is any way that commands like "mov rax,qword [Var+Reg64]" could be used? For example, to analyze, what in a command there is a reference to a variable which is being a segment of data, and to adjust reloc-section (if relocs used)? The structure of relocs allows to make it.
Post 11 Feb 2007, 01:46
View user's profile Send private message Visit poster's website MSN Messenger ICQ Number Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8430
Location: Kraków, Poland
Tomasz Grysztar 11 Feb 2007, 01:47
LocoDelAssembly wrote:
Oh, pardon Razz I thought that this problem was messing the relocations in some way.

But it's still a bug, even though a different one. fasm should detect that the value is out of range for sign extension. I will try to fix it too in the next release.
Post 11 Feb 2007, 01:47
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8430
Location: Kraków, Poland
Tomasz Grysztar 11 Feb 2007, 23:40
OK, this range checking has been corrected in 1.67.20.

Garthower wrote:
Whether and there is any way that commands like "mov rax,qword [Var+Reg64]" could be used? For example, to analyze, what in a command there is a reference to a variable which is being a segment of data, and to adjust reloc-section (if relocs used)? The structure of relocs allows to make it.

I don't really understand what do you mean here. See the quotation in my post above, which says about the need of explicit setting to make PE file relocatable in low 2GB.
Post 11 Feb 2007, 23:40
View user's profile Send private message Visit poster's website Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4623
Location: Argentina
LocoDelAssembly 11 Feb 2007, 23:57
Thanks Wink
Post 11 Feb 2007, 23:57
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< 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


Copyright © 1999-2025, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.