View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0014862||FPC||Compiler||public||2009-10-21 08:57||2010-11-26 13:57|
|Reporter||Enigma||Assigned To||Jonas Maebe|
|Product Version||2.5.1||Product Build|
|Target Version||Fixed in Version||2.6.0|
|Summary||0014862: Few Intel x64 assembler bugs|
|Description||I've noticed few assembler bugs, means bugs that occur when I use some "asm end;"... Everything here is related to Intel assembler type, x64.|
1. Compiler allows to write such code
but "pushad" is instruction of x32 assembler, in x64 there is no pushad/pushaq, there is no instructions that allows to push all registers to stack. Compiler generates $60 opcode for this command, but in WinDbg this opcode is known as invalid.
2. Same as 0000001 but with "popad"
3. Compiler allows to do this:
but in x64 assembler there is no such commands too. For x64 there are:
4. Also one bug... If I implement such record:
TOwnRecord = record
first_param : qword;
second_param : qword;
third_param : qword;
param : TOwnRecord;
then in assembler code I do the following:
lea rax, [rip + param]
mov TOwnRecord(rax).first_param, rcx
after compiling, the second line is changing from qword to dword, means, in WinDbg the second line looks:
mov dword ptr [rax + 0], ecx
but not as I require:
mov qword ptr [rax + 0], rcx
|Tags||No tags attached.|
|Fixed in Revision||15546|
one note also, when I want to insert "int 3" asm instruction, compiler generate opcode "$CD $03", but the better way is to use "$CC" opcode. It is smaller and could be used as a breakpoint for debuggers.
Currently, int 3 that FPC generates, with "$CD $03" opcode, allows to break in debugger, but WinDbg works incorrectly to step after this instruction.
One more note, in Windows x64 application, if I write asm:
sub rax, qword ptr [rcx]
comiler anyway compiles it to
sub eax, dword ptr [rcx]
i.e. translate my qword to dword and rcx to ecx.
||The correct mnemonic for opcode $CC is int3. This is different from "int 3", with a space.|
Ahhh, need to enter "int3"... wow... understand.. nice thing, thanks!
Also have found few bugs in assembler (x64).
if I try to write
mov rax, fs:[rcx]
mov rax, gs:[rcx]
compiler translate both these to just:
mov rax, [rcx]
without fs or gs.
PS: "mov rax, [rcx]" is the same as "mov rax, ds:[rcx]"
||The Intel assembler mode is used very little for 64 bit (because there is no existing Delphi code that uses it), so in a sense it's unfortunately logical that it still contains a lot of bugs...|
Sure, it is little specific.. Do you want me to post any other asm bugs here (if I find more..), or stop posting?
The higher deal for x64 application is supporting exceptions... Do you know, is this in progress, can we wait it soon or it is low priority?
It's best to open a separate bug report per problem. If someone fixes one problem, then they can immediately close that bug.
I don't know the status of dealing with exception handling in win64. I'm not involved in the Windows support.
Issues 1 to 3 were fixed in r15546
Issue 4 is tracked in 0016622
The issues in comments 0031580 and 0031675 seem to have been resolved already by another fix in the mean time.
|2009-10-21 08:57||Enigma||New Issue|
|2009-10-22 14:50||Enigma||Note Added: 0031578|
|2009-10-22 14:52||Enigma||Note Added: 0031580|
|2009-10-22 15:03||Jonas Maebe||Note Added: 0031582|
|2009-10-26 09:33||Enigma||Note Added: 0031675|
|2009-10-26 09:34||Enigma||Note Edited: 0031675|
|2009-10-26 09:41||Jonas Maebe||Note Added: 0031676|
|2009-10-26 11:12||Enigma||Note Added: 0031678|
|2009-10-26 11:27||Jonas Maebe||Note Added: 0031679|
|2010-07-10 18:43||Jonas Maebe||Relationship added||related to 0016622|
|2010-07-10 18:46||Jonas Maebe||Fixed in Revision||=> 15546|
|2010-07-10 18:46||Jonas Maebe||Status||new => resolved|
|2010-07-10 18:46||Jonas Maebe||Fixed in Version||=> 2.5.1|
|2010-07-10 18:46||Jonas Maebe||Resolution||open => fixed|
|2010-07-10 18:46||Jonas Maebe||Assigned To||=> Jonas Maebe|
|2010-07-10 18:46||Jonas Maebe||Note Added: 0039240|
|2010-11-26 13:57||Jonas Maebe||Status||resolved => closed|