Index
> Compiler Internals > [solved (AT&T syntax is different)] fsubr bug |
| Author |
|
|
LocoDelAssembly 15 Feb 2014, 19:09
Code: format pe gui 4.0 fsub st1,st0 fsubr st1,st0 fsubp st1,st0 fsubrp st1,st0 nop db 0xdc,0xe9 ; Produces fsub st1,st0 actually ret Code: .flat:00401000 ; .flat:00401000 ; +-------------------------------------------------------------------------+ .flat:00401000 ; ¦ This file is generated by The Interactive Disassembler (IDA) ¦ .flat:00401000 ; ¦ Copyright (c) 2010 by Hex-Rays SA, <support@hex-rays.com> ¦ .flat:00401000 ; ¦ Licensed to: Freeware version ¦ .flat:00401000 ; +-------------------------------------------------------------------------+ .flat:00401000 ; .flat:00401000 ; Input MD5 : 1611F3746E9F914183574CB760582847 .flat:00401000 .flat:00401000 ; File Name : C:\Users\Hernan\Desktop\seanm.exe .flat:00401000 ; Format : Portable executable for 80386 (PE) .flat:00401000 ; Imagebase : 400000 .flat:00401000 ; Section 1. (virtual address 00001000) .flat:00401000 ; Virtual size : 0000000C ( 12.) .flat:00401000 ; Section size in file : 00000200 ( 512.) .flat:00401000 ; Offset to raw data for section: 00000200 .flat:00401000 ; Flags E0000060: Text Data Executable Readable Writable .flat:00401000 ; Alignment : default .flat:00401000 .flat:00401000 .686p .flat:00401000 .mmx .flat:00401000 .model flat .flat:00401000 .flat:00401000 ; --------------------------------------------------------------------------- .flat:00401000 .flat:00401000 ; Segment type: Pure code .flat:00401000 ; Segment permissions: Read/Write/Execute .flat:00401000 _flat segment para public 'CODE' use32 .flat:00401000 assume cs:_flat .flat:00401000 ;org 401000h .flat:00401000 assume es:nothing, ss:nothing, ds:_flat, fs:nothing, gs:nothing .flat:00401000 .flat:00401000 ; ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ S U B R O U T I N E ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ .flat:00401000 .flat:00401000 .flat:00401000 public start .flat:00401000 start proc near .flat:00401000 fsub st(1), st .flat:00401002 fsubr st(1), st .flat:00401004 fsubp st(1), st .flat:00401006 fsubrp st(1), st .flat:00401008 nop .flat:00401009 fsub st(1), st .flat:0040100B retn .flat:0040100B start endp .flat:0040100B .flat:0040100B ; --------------------------------------------------------------------------- .flat:0040100C align 200h .flat:0040100C _flat ends .flat:0040100C .flat:0040100C .flat:0040100C end start |
|||
15 Feb 2014, 19:09 |
|
|
seanm 15 Feb 2014, 20:27
LocoDelAssembly wrote: Perhaps you got confused because GNU assembler uses src, dest operands order instead of dest, src as fasm (and any assembler following Intel Assembly syntax)? Normally I would say I may have, but I was using a program to convert from GNU to fasm and it reverses the order. I had over 5,200 lines of undocumented code to convert.... no way I was doing it by hand! I was using version 1.71.17 (I hope there will be a 1.71.17.1 
How I tested: 1) convert gnu as to fasm 2) run gdb and compare the disassembled output to the original code |
|||
|
15 Feb 2014, 20:27 |
|
|
revolution 16 Feb 2014, 02:19
seanm wrote: How I tested: |
|||
|
16 Feb 2014, 02:19 |
|
|
seanm 16 Feb 2014, 04:50
revolution wrote:
That could be. Strange it worked for everything except fsubr and fsubrp. Anyway, not a problem. I have a workaround. I just posted here in case others have the same problem. |
|||
|
16 Feb 2014, 04:50 |
|
|
revolution 16 Feb 2014, 05:12
seanm wrote: fsubr st1,st0 produced 0xdc,0xe1 when it should have produced 0xdc,0xe9. Quote: DC E0+i FSUBR ST(i), ST(0) |
|||
|
16 Feb 2014, 05:12 |
|
|
seanm 16 Feb 2014, 05:37
revolution wrote:
Interesting. Just for my info, what do they show for fsub? |
|||
|
16 Feb 2014, 05:37 |
|
|
revolution 16 Feb 2014, 06:08
seanm wrote: Interesting. Just for my info, what do they show for fsub? Quote: DC E8+i FSUB ST(i), ST(0) |
|||
|
16 Feb 2014, 06:08 |
|
|
baldr 16 Feb 2014, 07:20
seanm,
It's the quirk of Intel opcode encoding, D8 r/4 and D8 r/5 are fsub st, st(i) and fsubr st, st(i), but DC r/4 and DC r/5 are fsubr st(i), st and fsub st(i), st, i.e. order reversed (m/4 and m/5 encodings are consistent about fsub / fsubr); same for fdiv / fdivr. Perhaps that was made to simplify decode logic: bit 2 of primary opcode controls where result goes (0: TOS; 1: indexed register) and bit 3 of opcode extension (in Intel-speak ModR/M byte outside 00h-BFh range is the opcode extension entirely, for coprocessor escape instruction) indicates whether operands are swapped (with regard to natural st(0) op st(i) order). |
|||
|
16 Feb 2014, 07:20 |
|
|
revolution 16 Feb 2014, 07:39
baldr wrote: It's the quirk of Intel opcode encoding ... |
|||
|
16 Feb 2014, 07:39 |
|
|
seanm 16 Feb 2014, 21:34
Ok gotcha. So gnu as and fasm just disagree about fsub/fsubr and fsubp/fsubrp. So all I have to do is reverse the opcode when converting. I don't know why I didn't notice that Friday
 Much easier than my hack.
So I will fix the converter and should be good to go. Thanks! |
|||
|
16 Feb 2014, 21:34 |
|
|
revolution 16 Feb 2014, 21:47
seanm wrote: Ok gotcha. So gnu as and fasm just disagree about fsub/fsubr and fsubp/fsubrp. So all I have to do is reverse the opcode when converting. seanm wrote: So I will fix the converter and should be good to go. |
|||
|
16 Feb 2014, 21:47 |
|
|
LocoDelAssembly 17 Feb 2014, 01:37
Maybe this is related? http://linux.web.cern.ch/linux/scientific4/docs/rhel-as-en-4/i386-bugs.html
|
|||
|
17 Feb 2014, 01:37 |
|
|
revolution 17 Feb 2014, 01:44
LocoDelAssembly wrote: Maybe this is related? http://linux.web.cern.ch/linux/scientific4/docs/rhel-as-en-4/i386-bugs.html |
|||
|
17 Feb 2014, 01:44 |
|
< Last Thread | Next Thread > |
Forum Rules:
|