flat assembler
Message board for the users of flat assembler.
![]() Goto page 1, 2 Next |
Author |
|
revolution
Try jmp near dword [label+reg+reg*8]
|
|||
![]() |
|
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? |
|||
![]() |
|
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? |
|||
![]() |
|
MazeGen
It does, of course
![]() 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 $ |
|||
![]() |
|
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.
|
|||
![]() |
|
vid
MazeGen:
![]() |
|||
![]() |
|
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. |
|||
![]() |
|
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. |
|||
![]() |
|
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. |
|||
![]() |
|
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. |
|||
![]() |
|
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?
|
|||
![]() |
|
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? |
|||
![]() |
|
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. |
|||
![]() |
|
vid
just an idea: isn't PE file without reloc section always "fixed"?
|
|||
![]() |
|
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. |
|||
![]() |
|
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.
![]() 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. |
|||
![]() |
|
vid
great, thanks. just wondering - how do you know whether there is or is not "fixups data"? one more pass, or prediction, or how?
|
|||
![]() |
|
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,...)!!!!!! |
|||
![]() |
|
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. |
|||
![]() |
|
Goto page 1, 2 Next < Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.
Website powered by rwasa.