Index
> Main > 32-bit relocations in 64-bit objects / non-relocatable PEsGoto page Previous 1, 2 |
| Author |
|
|
vid 29 Jun 2006, 11:36
remy: macros are much less complicated since 1.64. and you won't even notice there is anything with 64bits addedd, unlesss you explicitly request it.
|
|||
29 Jun 2006, 11:36 |
|
|
Madis731 29 Jun 2006, 11:54
@Tomasz: Does this mean that I can delete the "org" commands from MenuetOS sources or aren't these two problems related. I don't quite understand what these relocations do.
As in: Code: use64 jmp dword +12345678h ;some junk label_12345678h_bytes_away: ? Its pseudo so it won't work, but is the principle right? |
|||
|
29 Jun 2006, 11:54 |
|
|
Remy Vincent 29 Jun 2006, 12:43
Tomasz Grysztar wrote: There shouldn't be any difference for you in using the version with 64-bit mode support unless....... My point of vue is that it "hurts me inside" to use a compiler that I'm not sure IT IS WITH ZERO BUG... My FASM 1.51 fill me with "100% sure DOS progams will be running"... that's great for me!! But using the FASM 1.66 version.., I can't put away the following DOUBT : are 16bit instructions still properly assembled ?? or because of 64 bits instructions new bugs are existing... ... ...May be a solution for me would be to compare FASM 1.51 OUTPUT and FASM 1.66 OUTPUT ( With DOS program mode )... so I would be sure the new FASM is still ok for 16bits instructions... |
|||
|
29 Jun 2006, 12:43 |
|
|
Tomasz Grysztar 29 Jun 2006, 14:08
Remy Vincent: actually there were even some bugs that were fixed while the 64-bit support was added. While implementing the AMD64 architecture I did a massive cleanup of many internal routines and fixed many small problems this way. Also many more fixes came later. For example please take:
Code: org 0 jmp 0FFFFh and compare how it's assembled with 1.52 and how with 1.67 (it's 16-bit code). Or even: Code: org 80000000h jmp 0FFFFh (though this is more unusual application). And as you can see even in this thread, each time I add a new feature, it's of high priority for me to make it not interfere with the already existing ones in a bad way. |
|||
|
29 Jun 2006, 14:08 |
|
|
Tomasz Grysztar 29 Jun 2006, 14:09
Madis731 wrote: @Tomasz: Does this mean that I can delete the "org" commands from MenuetOS sources or aren't these two problems related. I don't quite understand what these relocations do. AFAIK, the MenuetOS doesn't use object formats, thus all your addressing is absolute - the relocations topic is here unrelated really. |
|||
|
29 Jun 2006, 14:09 |
|
|
quiveror 29 Jun 2006, 18:51
Thanks for the 1.67, I'm checking it out
 |
|||
|
29 Jun 2006, 18:51 |
|
|
rugxulo 30 Jun 2006, 04:44
All programs have bugs, even FASM. You can only fix them if you find them. You can only find them if you use the program regularly.
|
|||
|
30 Jun 2006, 04:44 |
|
|
Tomasz Grysztar 30 Jun 2006, 11:50
Also, for those reasons, I now keep the development line as the only available version, to prevent confusion - the rule is: always use the latest version, and something doesn't work for you - please report it.
|
|||
|
30 Jun 2006, 11:50 |
|
|
Tomasz Grysztar 30 Jun 2006, 11:56
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.
|
|||
|
30 Jun 2006, 11:56 |
|
|
vid 02 Jul 2006, 08:51
Tomasz Grysztar wrote: Also, for those reasons, I now keep the development line as the only available version, to prevent confusion - the rule is: always use the latest version, and something doesn't work for you - please report it. it's not that easy with silent updates |
|||
|
02 Jul 2006, 08:51 |
|
|
Tomasz Grysztar 02 Jul 2006, 09:38
With dev line there are no silent updates.
|
|||
|
02 Jul 2006, 09:38 |
|
|
vid 02 Jul 2006, 14:48
now please rename thread to something like "Fixed symbols in PE" or so... this name isn't very descriptive
 |
|||
|
02 Jul 2006, 14:48 |
|
|
Garthower 21 Sep 2006, 10:12
Hello Tomasz Grysztar! You don't wish to return again to given "problem"? Without reloc section in a final PE-file it is possible to manage, but at writing DLL it practically isn't possible (there is a truth the roundabout ways connected with relative addressing, but such ways very much are not convenient in a writing). Often it's need to use commands of a kind, for example,
Code: mov reg8, byte [Address+reg64] FASM refuses similar to compile commands at use in the initial text reloc section. It's need to break one command on two, for example, Code: lea reg64,[Address] mov reg8,[reg64+reg64] and it's not convenient. |
|||
|
21 Sep 2006, 10:12 |
|
|
Tomasz Grysztar 17 Feb 2007, 15:54
I have tested that 32-bit relocation seems to cause no problems in 64-bit DLLs on WinXP. It appears that no additional flagging of PE file is really needed. Thus the 1.67.21 release allows the constructs like above in the regular relocatable PE.
|
|||
|
17 Feb 2007, 15:54 |
|
|
Garthower 18 Feb 2007, 14:10
Thanks Tomasz for this fix! I waited for it during many months!
|
|||
|
18 Feb 2007, 14:10 |
|
|
Tomasz Grysztar 18 Feb 2007, 14:53
I apologize that I didn't realize/check earlier that this may actually work without additional flags. That was the only reason why you had to wait so long.
|
|||
|
18 Feb 2007, 14:53 |
|
| Goto page Previous 1, 2 < Last Thread | Next Thread > |
Forum Rules:
|