flat assembler
Message board for the users of flat assembler.

Index > Main > 32-bit relocations in 64-bit objects / non-relocatable PEs

Goto page 1, 2  Next
Author
Thread Post new topic Reply to topic
Garthower



Joined: 21 Apr 2006
Posts: 158
Location: Ukraine
Garthower 22 Jun 2006, 10:04
How correctly to write down command a kind in TASM "jmp dword ptr [offset label1+reg1+reg2*8]"? FASM 1.66 gives out a mistake "illegal instruction" on command "jmp dword [label1++reg1+reg2*8]".


Last edited by Garthower on 03 Jul 2006, 10:40; edited 2 times in total
Post 22 Jun 2006, 10:04
View user's profile Send private message Visit poster's website MSN Messenger ICQ Number Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 19874
Location: In your JS exploiting you and your system
revolution 22 Jun 2006, 11:01
Try jmp near dword [label+reg+reg*8]
Post 22 Jun 2006, 11:01
View user's profile Send private message Visit poster's website Reply with quote
Garthower



Joined: 21 Apr 2006
Posts: 158
Location: Ukraine
Garthower 22 Jun 2006, 11:25
Thanks, it works. But I have faced one more problem - in a 32-bit mode all is compiled wonderfully, and in x64-86 - is not present. Again returns a mistake "illegal size of address value". I use this source:

Code:
        jmp near qword [Proc_Addr_Table+rax+rsi*8]
;------------------------------------------------------------------------------
Proc_Addr_Table:
        dq Addr1
        dq Addr2
    


Where is a bug? May be x64-86 mode does not support this command? Or this is mistake of the compiler?
Post 22 Jun 2006, 11:25
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: 4624
Location: Argentina
LocoDelAssembly 23 Jun 2006, 16:30
Code:
format PE64 GUI

        jmp qword [Proc_Addr_Table+rax+rsi*8]
;------------------------------------------------------------------------------ 
Proc_Addr_Table: 
        dq Addr1
        dq Addr2

Addr1:
        nop
Addr2:
        jmp $    
Tells me "address sizes do not agree"

PS: Maybe AMD64 doesn't support 64-bit offset?
Post 23 Jun 2006, 16:30
View user's profile Send private message Reply with quote
MazeGen



Joined: 06 Oct 2003
Posts: 977
Location: Czechoslovakia
MazeGen 23 Jun 2006, 17:09
It does, of course Smile It seems to be a bug in FASM. MASM 64 assembles it successfuly:
Code:
 00000000  FF A4 F0                     jmp     qword ptr [Proc_Addr_Table+rax+rsi*8]
           00000007 R

 00000007                       Proc_Addr_Table: 
 00000007  0000000000000017 R           dq Addr1
 0000000F  0000000000000018 R           dq Addr2

 00000017                       Addr1:
 00000017  90                           nop
 00000018                       Addr2:
 00000018  EB FE                        jmp $
    
Post 23 Jun 2006, 17:09
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8268
Location: Kraków, Poland
Tomasz Grysztar 23 Jun 2006, 18:43
This will work with absolute addressing only, there's no imm64+reg, nor RIP+imm32+reg addressing in AMD64 architecture which makes it impossible to generate such instruction with relocatable 64-bit addressing.
Post 23 Jun 2006, 18:43
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid 24 Jun 2006, 14:02
MazeGen: Razz
Post 24 Jun 2006, 14:02
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
quiveror



Joined: 20 Jun 2003
Posts: 34
quiveror 25 Jun 2006, 18:54
Code:
jmp     qword ptr [Proc_Addr_Table+rax+rsi*8]    

I use 'dumpbin' to example the coff64 object file generated by masm and found that, for the above instruction, it produced ADDR32 relocation. This is absolute 32-bit relocation which is feasible to use when the whole image lies below 2Gig of virtual memory.
Post 25 Jun 2006, 18:54
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8268
Location: Kraków, Poland
Tomasz Grysztar 25 Jun 2006, 20:43
fasm doesn't currently know such kind of relocations, sorry. It would need to have somehow specified that the resulting code can work only in low 2 GB, as it would affect encoding of other instructions aswell.
The 64-bit code generated by fasm is made to be position-independent.
Post 25 Jun 2006, 20:43
View user's profile Send private message Visit poster's website Reply with quote
Borsuc



Joined: 29 Dec 2005
Posts: 2465
Location: Bucharest, Romania
Borsuc 26 Jun 2006, 16:11
Tomasz Grysztar wrote:
fasm doesn't currently know such kind of relocations, sorry. It would need to have somehow specified that the resulting code can work only in low 2 GB, as it would affect encoding of other instructions aswell.
The 64-bit code generated by fasm is made to be position-independent.
Why not add some command line switch or directive to accompany "use64" and make it work like that, or is it such a bad idea?
Post 26 Jun 2006, 16:11
View user's profile Send private message Reply with quote
quiveror



Joined: 20 Jun 2003
Posts: 34
quiveror 27 Jun 2006, 09:04
Tomasz Grysztar wrote:
It would need to have somehow specified that the resulting code can work only in low 2 GB, as it would affect encoding of other instructions aswell.

Actually, m$ linker can do that, just use /base and /fixed switches. It also gives an error(or maybe warning) message if it's impossible to correctly resolve a ADDR32 relocation.
Post 27 Jun 2006, 09:04
View user's profile Send private message Reply with quote
Garthower



Joined: 21 Apr 2006
Posts: 158
Location: Ukraine
Garthower 27 Jun 2006, 09:17
As I have understood, it is a problem on a straight line is connected with a mistake of the compiler and\or linker. Whether It is possible to hope, what in the future versions of FASM this situation somehow to change?
Post 27 Jun 2006, 09:17
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: 8268
Location: Kraków, Poland
Tomasz Grysztar 27 Jun 2006, 09:47
It's was intended and thoughtful behavior of assembler - I wanted to "promote" what in my opinion is a better way of using AMD64 architecture. Using 32-bit absolute addresses everywhere makes instructions larger ("xor al,[rip+0]" is smaller than "xor al,[dword 0]", and note that for "xor al,[dword 80000000h]" fasm even has to generate 67h prefix, to prevent the sign-extension), while using them selectivelly makes code unequable. You can force absolute addressing like in the above examples if you like - though it won't work with relocatable formats, as noted.
To make it work, there perhaps would be a solution to add some settings for relocatable formats, one to force generating code for low 2 GB, and maybe even one more for low 4 GB (with 67h prefix in such places).

I will try to invent some better solution, but as I would like the making of 2GB-limit-dependent code to be the aware choice of the programmer, and so perhaps leave the plain instruction of such type signalizing an error, it won't be so easy... Or should I depend on the linker/loader to warn the programmer?
Post 27 Jun 2006, 09:47
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8268
Location: Kraków, Poland
Tomasz Grysztar 27 Jun 2006, 10:13
It seems I myself did all the discussion I needed. Very Happy
I will try adding support for such relocations as soon as I have some more time.

And perhaps at the same time I would finally add the FIXED option for the PE format, to replace those silly macros from the FAQ.
Post 27 Jun 2006, 10:13
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid 27 Jun 2006, 10:56
just an idea: isn't PE file without reloc section always "fixed"?
Post 27 Jun 2006, 10:56
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8268
Location: Kraków, Poland
Tomasz Grysztar 27 Jun 2006, 11:28
I recall there was some problem, because of which the fixed/relocatable cannot be changed "on-the-fly" during resolving. Some limitation of the current implementation... I will try to re-approach this problem, though.

On the other hand - some very old fasm versions were automatically generating fixups section at the end of executable if not told where to put it - I could bring it back while implementing FIXED option.
Post 27 Jun 2006, 11:28
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8268
Location: Kraków, Poland
Tomasz Grysztar 29 Jun 2006, 00:39
OK, it seems that because I forgot what were the problems, I managed to do it now and it appears to be working. Wink Check out the 1.67.0 release - it supports the 32-bit relocations in 64-bit object format generated automatically by assembler in those situations when there's no other alternative (I decided I will rely on linker to warn the programmer about the code placing limitations, and thus fasm will obediently produce such instruction when told to, in case of object output). It also automatically switches the type of labels between fixed and relocatable depending on whether you include fixups data in PE, or not.

Both those solution require no additional switches and should (I hope) have no unwanted effects on the earlier-working sources. Please check it out carefully, though.
Post 29 Jun 2006, 00:39
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid 29 Jun 2006, 09:05
great, thanks. just wondering - how do you know whether there is or is not "fixups data"? one more pass, or prediction, or how?
Post 29 Jun 2006, 09:05
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Remy Vincent



Joined: 16 Sep 2005
Posts: 155
Location: France
Remy Vincent 29 Jun 2006, 10:09
Tomasz Grysztar wrote:
OK, it seems that because I forgot what were the problems, I managed to do it now and it appears to be working. Wink Check out the 1.67.0 release - it supports the 32-bit relocations in 64-bit object............ Please check it out carefully, though.



I have kept a "Non 64 bit" version of FASM.., the 1.51 version of FASM... ?

Would it be usefull to add a "Non 64 bit" version of FASM in the main download page of flatassembler.net ????

For example, I can't download FASM 1.67 ( even if version 1.67 works surely very well ) because it contains too many "very complex" options (64 bit,macros,...)!!!!!!
Post 29 Jun 2006, 10:09
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8268
Location: Kraków, Poland
Tomasz Grysztar 29 Jun 2006, 11:09
vid wrote:
great, thanks. just wondering - how do you know whether there is or is not "fixups data"? one more pass, or prediction, or how?

Resolving as usual, the prediction is by default that there are no fixups, and if there were fixups in the previous pass, the prediction is that there are - simple.
Post 29 Jun 2006, 11:09
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page 1, 2  Next

< 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-2023, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.