Index
> Main > 32-bit relocations in 64-bit objects / non-relocatable PEsGoto page 1, 2 Next |
| Author |
|
|
revolution
Try jmp near dword [label+reg+reg*8]
|
|||
22 Jun 2006, 11:01 |
|
|
Garthower
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? |
|||
|
22 Jun 2006, 11:25 |
|
|
LocoDelAssembly
Code: format PE64 GUI
jmp qword [Proc_Addr_Table+rax+rsi*8]
;------------------------------------------------------------------------------
Proc_Addr_Table:
dq Addr1
dq Addr2
Addr1:
nop
Addr2:
jmp $ PS: Maybe AMD64 doesn't support 64-bit offset? |
|||
|
23 Jun 2006, 16:30 |
|
|
MazeGen
It does, of course
 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 $ |
|||
|
23 Jun 2006, 17:09 |
|
|
Tomasz Grysztar
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.
|
|||
|
23 Jun 2006, 18:43 |
|
|
vid
MazeGen:
 |
|||
|
24 Jun 2006, 14:02 |
|
|
quiveror
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. |
|||
|
25 Jun 2006, 18:54 |
|
|
Tomasz Grysztar
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. |
|||
|
25 Jun 2006, 20:43 |
|
|
Borsuc
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. |
|||
|
26 Jun 2006, 16:11 |
|
|
quiveror
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. |
|||
|
27 Jun 2006, 09:04 |
|
|
Garthower
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?
|
|||
|
27 Jun 2006, 09:17 |
|
|
Tomasz Grysztar
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? |
|||
|
27 Jun 2006, 09:47 |
|
|
Tomasz Grysztar
It seems I myself did all the discussion I needed.
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. |
|||
|
27 Jun 2006, 10:13 |
|
|
vid
just an idea: isn't PE file without reloc section always "fixed"?
|
|||
|
27 Jun 2006, 10:56 |
|
|
Tomasz Grysztar
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. |
|||
|
27 Jun 2006, 11:28 |
|
|
Tomasz Grysztar
OK, it seems that because I forgot what were the problems, I managed to do it now and it appears to be working.
 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. |
|||
|
29 Jun 2006, 00:39 |
|
|
vid
great, thanks. just wondering - how do you know whether there is or is not "fixups data"? one more pass, or prediction, or how?
|
|||
|
29 Jun 2006, 09:05 |
|
|
Remy Vincent
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. 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,...)!!!!!! |
|||
|
29 Jun 2006, 10:09 |
|
|
Tomasz Grysztar
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. |
|||
|
29 Jun 2006, 11:09 |
|
| Goto page 1, 2 Next < Last Thread | Next Thread > |
Forum Rules:
|