flat assembler
Message board for the users of flat assembler.

Index > Compiler Internals > [solved (AT&T syntax is different)] fsubr bug

Author
Thread Post new topic Reply to topic
seanm



Joined: 15 Feb 2014
Posts: 5
seanm
I was porting some code from gnu as to fasm and I found that the fsubr and fsubrp instructions where converted to fsub and fsubp in the output code.

I worked around it by hardcoding the machine code with db bytes.

Example:

fsubr st1,st0 produced 0xdc,0xe1 when it should have produced 0xdc,0xe9.
Post 15 Feb 2014, 18:24
View user's profile Send private message Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
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    
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)?
Post 15 Feb 2014, 19:09
View user's profile Send private message Reply with quote
seanm



Joined: 15 Feb 2014
Posts: 5
seanm
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 Wink

How I tested:

1) convert gnu as to fasm
2) run gdb and compare the disassembled output to the original code
Post 15 Feb 2014, 20:27
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17635
Location: In your JS exploiting you and your system
revolution
seanm wrote:
How I tested:

1) convert gnu as to fasm
2) run gdb and compare the disassembled output to the original code
The fault is at step 1. Your converter program is broken.
Post 16 Feb 2014, 02:19
View user's profile Send private message Visit poster's website Reply with quote
seanm



Joined: 15 Feb 2014
Posts: 5
seanm
revolution wrote:
seanm wrote:
How I tested:

1) convert gnu as to fasm
2) run gdb and compare the disassembled output to the original code
The fault is at step 1. Your converter program is broken.


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.
Post 16 Feb 2014, 04:50
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17635
Location: In your JS exploiting you and your system
revolution
seanm wrote:
fsubr st1,st0 produced 0xdc,0xe1 when it should have produced 0xdc,0xe9.
The Intel manual is very clear about this:
Quote:
DC E0+i FSUBR ST(i), ST(0)
Post 16 Feb 2014, 05:12
View user's profile Send private message Visit poster's website Reply with quote
seanm



Joined: 15 Feb 2014
Posts: 5
seanm
revolution wrote:
seanm wrote:
fsubr st1,st0 produced 0xdc,0xe1 when it should have produced 0xdc,0xe9.
The Intel manual is very clear about this:
Quote:
DC E0+i FSUBR ST(i), ST(0)


Interesting. Just for my info, what do they show for fsub?
Post 16 Feb 2014, 05:37
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17635
Location: In your JS exploiting you and your system
revolution
seanm wrote:
Interesting. Just for my info, what do they show for fsub?
Quote:
DC E8+i FSUB ST(i), ST(0)
You can download your own version of the manual from Intel's site. AMD has a manual also. Both are free.
Post 16 Feb 2014, 06:08
View user's profile Send private message Visit poster's website Reply with quote
baldr



Joined: 19 Mar 2008
Posts: 1651
baldr
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).
Post 16 Feb 2014, 07:20
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17635
Location: In your JS exploiting you and your system
revolution
baldr wrote:
It's the quirk of Intel opcode encoding ...
Actually I would blame the opcode mnemonics. One of the worst culprits is LEA; it should have been a more obvious three/four/five operand add. fsub(r)(p) and its friends deserved a better mnemonic and operand expression. But, too late to change that now.
Post 16 Feb 2014, 07:39
View user's profile Send private message Visit poster's website Reply with quote
seanm



Joined: 15 Feb 2014
Posts: 5
seanm
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 Sad Much easier than my hack.

So I will fix the converter and should be good to go.

Thanks!
Post 16 Feb 2014, 21:34
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17635
Location: In your JS exploiting you and your system
revolution
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.
So are you saying that GNU assembles it incorrectly? To say that GNU and fasm disagree in kind of understating it. Perhaps you mean GNU disagrees with every other assembler in the world? Or ...
seanm wrote:
So I will fix the converter and should be good to go.
... that your converter is converting incorrectly? This second option seems more likely. Both GNU and fasm are used by many people for various purposes and I find it difficult to imagine either one messing up fsub and not have someone notice the problem after all these years.
Post 16 Feb 2014, 21:47
View user's profile Send private message Visit poster's website Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
Post 17 Feb 2014, 01:37
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17635
Location: In your JS exploiting you and your system
revolution
Wow. AT&T syntax is worse than I thought. They have known bugs but for legacy reasons they just leave them there. vid should add that one to his article.
Post 17 Feb 2014, 01:44
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.