different results on using intel syntax and at&t syntax

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

different results on using intel syntax and at&t syntax

nix noob
there appears to be a problem i am not aware how i can
get rid of that

i use .intel_syntax no prefix
in my sample simpwind.s

i first did
.equ NEWT_KEY_UP,0x8001
.equ NEWT_KEY_DOWN,0x8002 etc

and tried to use them instead of hardcoding them on
compare
 
cmp eax, NEWT_KEY_UP

it gets assembled to

cmp eax,ds:0x8001
and then segfaults

just to see if it segfaults on at&t syntax too
i just over rid one single line with .att_syntax

keyup:
        .att_syntax             <--- over rode here
        cmp $NEWT_KEY_UP,%eax  
        .intel_syntax noprefix   <-- reset back
        jne keydown
        dec dword ptr ds:[upkey]
        invoke move_window
        jmp loop_start
keydown:
        cmp eax,NEWT_KEY_DOWN
        jne keyleft
        inc dword ptr ds:[upkey]
        invoke move_window
        jmp loop_start


and att syntax doesnt do that ds:0x8001

the disassembly is as follows

0x8048466 <newtInit+98>:        lea    esp,[esp*1+12]
0x804846a <newtInit+102>:       call   0x80483a4
<newtRefresh>
0x804846f <newtInit+107>:       lea    esp,[esp*1]
0x8048473 <newtInit+111>:       call   0x80483d4
<newtGetKey>
0x8048478 <newtInit+116>:       lea    esp,[esp*1]
0x804847c <newtInit+120>:       cmp    eax,0x8001  
<------
0x8048481 <newtInit+125>:       jne    0x8048494
<newtInit+144>
0x8048483 <newtInit+127>:       dec    ds:0x8049660
0x8048489 <newtInit+133>:       call   0x80484fb
<newtInit+247>
0x804848e <newtInit+138>:       lea    esp,[esp*1]
0x8048492 <newtInit+142>:       jmp    0x8048473
<newtInit+111>
0x8048494 <newtInit+144>:       cmp    eax,ds:0x8002
<-------
0x804849a <newtInit+150>:       jne    0x80484ad
<newtInit+169>
0x804849c <newtInit+152>:       inc    ds:0x8049660
0x80484a2 <newtInit+158>:       call   0x80484fb
<newtInit+247>

can some one explain how i can eliminate this problem

thanks and regards




       
               
__________________________________
Yahoo! for Good - Make a difference this year.
http://brand.yahoo.com/cybergivingweek2005/

Reply | Threaded
Open this post in threaded view
|

RE: different results on using intel syntax and at&t syntax

Dave Korn
nix noob wrote:
> there appears to be a problem i am not aware how i can
> get rid of that

> .equ NEWT_KEY_UP,0x8001

> cmp eax, NEWT_KEY_UP
>
> it gets assembled to
>
> cmp eax,ds:0x8001
> and then segfaults

>         .att_syntax             <--- over rode here
>         cmp $NEWT_KEY_UP,%eax
>         .intel_syntax noprefix   <-- reset back


> 0x804847c <newtInit+120>:       cmp    eax,0x8001

> can some one explain how i can eliminate this problem

  I can't reproduce your problem.  Both syntaxes give me the same result and
neither gives a ds: memory reference.  I even tried using '.set', '.equ' and
'=' to cause the problem but it still doesn't happen.

-------------------------------------------------------------------------
dk@espanola ~> as -ahls -
    .intel_syntax noprefix
    cmp eax, 0x8001
    .att_syntax
    cmp $0x8001, %eax
    .intel_syntax noprefix
.equ foobar, 0x8001
.set barfoo, 0x8001
quux = 0x8001
    cmp eax, 0x8001
    cmp eax, foobar
    cmp eax, barfoo
    cmp eax, quux
    cmp eax, 0x8001
    .end

GAS LISTING                     page 1


   1                    .intel_syntax noprefix
   2 0000 3D018000      cmp eax,0x8001
   2      00
   3                    .att_syntax
   4 0005 3D018000      cmp $0x8001,%eax
   4      00
   5                    .intel_syntax noprefix
   6                    .equ foobar,0x8001
   7                    .set barfoo,0x8001
   8                    quux =0x8001
   9 000a 3D018000      cmp eax,0x8001
   9      00
  10 000f 3D018000      cmp eax,foobar
  10      00
  11 0014 3D018000      cmp eax,barfoo
  11      00
  12 0019 3D018000      cmp eax,quux
  12      00
  13 001e 3D018000      cmp eax,0x8001
  13      00
  14 0023 90909090      .end
  14      90909090
  14      90909090
  14      90
GAS LISTING                    page 2


DEFINED SYMBOLS
                            *ABS*:00000000 fake

NO UNDEFINED SYMBOLS
dk@espanola ~>
-------------------------------------------------------------------------

  What binutils version are you using?  I've got 2.16.91 (i686-pc-cygwin) and
it appears to work just fine.

    cheers,
      DaveK
--
Can't think of a witty .sigline today....


Reply | Threaded
Open this post in threaded view
|

RE: different results on using intel syntax and at&t syntax

Dave Korn
In reply to this post by nix noob
nix noob wrote:
> Dave Korn,

[  Hi NN, you sent this reply to me only, but since it's nothing personal and
the information might be useful for anyone else who has the same problem I've
added the binutils list back into the Cc line.  ]
 
> thanks for replying when i posted this i had access
> two as(1) one was version 2.13 (redhat) other was
> 2.14.... (SuseLinux-9.0 i586 last official as it
> seemed no update was avl to that )

> but in the mean time i asked some one with 2.16 to
> test this code
> and it seems 2.16 behaves quiet correctly as would be
> expected
> may be it was fixed some times between 2.14 and 2.16

  That would make sense.  It's often the case that a bug has already been
fixed in the newest version by the time someone gets to


> here is a listing on those two as version

>    5                        .intel_syntax noprefix
>    6                    .equ foobar, 0x8001
>    7                    .set barfoo, 0x8001
>    8                    quux = 0x8001
>    9 000a 3D018000          cmp eax, 0x8001
>    9      00
>   10 000f 3B050180          cmp eax, foobar
>   10      0000
>   11 0015 3B050180          cmp eax, barfoo
>   11      0000
>   12 001b 3B050180          cmp eax, quux
>   12      0000
>   13 0021 3D018000          cmp eax, 0x8001
>   13      00
>   14                        .end

> see 3b050180 :)

  Aha!  So we have the beginning of our answer now: it seems that any symbol
generated by .equ/.set/= was being treated as a memory offset, rather than a
constant value that could potentially be an immediate operand.

  If you ever run into problems like this again, and you want to use proper
symbols for numeric constants but can't because of some problem it would
trigger, there is another technique often used: add C-style #define statements
to your assembler file instead of .equ, and use the C preprocessor on the
source before it gets assembled by using "gcc -x assembler-with-cpp" to
compile it instead of "as".

> i coulndt find in those binutils changelog diffs  when
> this behaviour was changed

  In case you don't know yet, there are separate ChangeLogs for each of the
main directories in the binutils source.  You should have been checking the
one in the gas subdirectory, not the main (toplevel) changelog nor the one in
the binutils dir.  (Just trying to be clear).

> since it seems fixed in latest version i think i have
> to upgrade
> ill ask for getting it updated
> sorry for the annoyance

  No annoyance caused, no apologies needed - you have come across a genuine
problem with the assembler, and it's fortunately fixed already.  I took a look
through the gas changelog for you, and I couldn't see what change might have
caused it either, but I was only searching for 'i386', and if it was a generic
change that affected the handling of symbols-vs-constants for all targets I
would have overlooked it.

    cheers,
      DaveK
--
Can't think of a witty .sigline today....


Reply | Threaded
Open this post in threaded view
|

RE: different results on using intel syntax and at&t syntax

nix noob
Dave Korn,

> [  Hi NN, you sent this reply to me only, but since
> it's nothing personal and
> the information might be useful for anyone else who
> has the same problem I've
> added the binutils list back into the Cc line.  ]

thanks for adding it as possible follow up (i had hit
reply insted of reply to everyone and noticed the goof
up only after
i had posted so i sent one to binutils@sources but it
got converted to a new thread :) and i was hoping some
one would pluck it and stick it here :) thanks for
that


>   If you ever run into problems like this again, and
> you want to use proper
> symbols for numeric constants but can't because of
> some problem it would
> trigger, there is another technique often used: add
> C-style #define statements
> to your assembler file instead of .equ, and use the
> C preprocessor on the
> source before it gets assembled by using "gcc -x
> assembler-with-cpp" to
> compile it instead of "as".

well i was trying to avoid gcc dependance completely
and wanted to assemble and link with as and ld only
but thanks for the pointers i sure would do that since

i cant be conveting the .h to .inc (is there a h2inc
that converts c header files to as include files ala
microsoft style
H2INC.exe that creates masm compatible inc files ??
well i searched and see one big long perl script
floating in kernel.sec mailing list but i dont know if
it works


 
>   In case you don't know yet, there are separate
> ChangeLogs for each of the
> main directories in the binutils source.  You should
> have been checking the
> one in the gas subdirectory, not the main (toplevel)
> changelog nor the one in
> the binutils dir.  (Just trying to be clear).
>

well like my nick states i am not much aware of the
way that works i wanted to write an assembly program
and found as(1) to be too much of a headache to use
and every one who was some one just asked me to use
nasm,fasm,etc (not many were even aware of this
.intel_syntax pseudo-op or directive what ever it was
i couldnt find a decent looking tut that was written
in pure
assembly using intel syntax assembled and linked with
as and ld only

if you noticed my first post you might see an invoke
statement in there also in the disassembly you might
notice an lea esp,[esp+1*4]

actually i faced this problem when i made that macro
i did add esp,narg*4  narg == no of args passed to
invoke
and the disassembly turned out to be
add esp,[narg]  
ie if narg was 2,3,4 the disassembly was
add esp ,[8] | add esp,[0x0c]  | add esp,[0x10] and
was segfaulting
so i just utilised the behaviour as it is thinking it
might be some gas magic :)
and converted the expansion to lea esp,[esp+narg*4] so
that it worked

and the macro that i made is looking absolutely logic
less and i dont know why such code should work but
unfortunately it works :(
but i was surprised to find that a code which should
work flawlessly was not working

thanks and regards

nix noob



               
__________________________________________
Yahoo! DSL – Something to write home about.
Just $16.99/mo. or less.
dsl.yahoo.com