Re: Help translating Intel to AT&T
From: Frank Kotler (fbkotler_at_comcast.net)
Date: 04/13/04
- Previous message: Grumble: "Re: stack pointer part 2"
- In reply to: Ray: "Re: Help translating Intel to AT&T"
- Next in thread: Ray: "Re: Help translating Intel to AT&T"
- Reply: Ray: "Re: Help translating Intel to AT&T"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 13 Apr 2004 11:16:13 +0000 (UTC)
Ray wrote:
> Frank Kotler <fbkotler@comcast.net> wrote in message news:<407AF4AB.7040900@comcast.net>...
>
>>Ray wrote:
>>
>>
>>> movl buf, %ecx # we are putting the ADDRESS
>>>of buf in ecx
>>
>>I could be mistaken - translating in the other direction is more my
>>thing - but I think you want "$buf" for the address...
>
>
> I tried that too, but it didn't work either. What persuaded me to use
> buf instead was the fact that the comments in the Nasm source
> emphasized that they were "putting the ADDRESS of buf in ecx."
Right. You definitely want the address here. In *Nasm* syntax:
mov ecx, buf ; address of buf
mov ecx, [buf] ; contents (first 4 bytes) of buf
I *think* the Gas syntax would be:
movl $buf, %ecx # address of buf
movl buf, %ecx # contents of buf
but maybe:
movl (buf), %ecx # ???
But I'm Nasmist, and don't use BSD, so I'm doubly out of my depth here!
>>Have you tried "intel2gas"?
>>
>>http://www.niksula.cs.hut.fi/~mtiihone/intel2gas/
>
>
> I've thought of that, but the document where I copied this from
> doesn't have a couplete source code either--buf and bufsize aren't
> defined.
Ah, Hmmm. They're not, are they... And it's relevant, too! Well...
buf resb 8192
in some form... perhaps:
bufsiz equ 8192
buf resd bufsiz
probably would be more "traditional" to call it BUFSIZ if we were going
to do it that way. Or:
bufsiz dd 8192
buf resd bufsiz
in which case, bufsiz is a variable, and has an address... Jonathan says:
mov ecx, buf ; we are putting the ADDRESS of buf in ecx
mov edx, bufsize ; we are putting the ADDRESS of bufsize in edx
Now, address of buf in ecx is correct, but if "bufsize" is a variable,
you want it's [contents] in edx, *not* the address! "bufsize" must be
"bufsize equ 8192", for this to work. In your Gas translation of this
example, you made it a variable, so I think what you had for that is okay:
movl buf, %ecx # we are putting the ADDRESS
of buf in ecx
movl bufsize, %edx # we are putting the ADDRESS
of buffsize in edx
Well, I take it back - the comment is wrong... but I think it'll do
what you want. Jonathan's error (in the comment), not yours. If you'd
done it like the example below, where the size is "=", you'd want the
"$". But I think you want "$buf" - the address - in that line... but...
>>Mmmm... you said BSD, right? I think BSD does syscalls differently than
>>Linux... parameters pushed instead of put in registers, and a "call" to
>>a "int 80h"/"ret" stub... closer to a C calling convention... not sure
>>about that one, either! What gives me that impression is the macros in
>>the "asmutils" package at http://linuxassembly.org (they're for Nasm, so
>>you won't be able to use 'em directly) . Do you have any working
>>example that uses the int 80h interface in BSD? You may have more to
>>cope with than just syntax differences :(
>
>
> Yeah, I have a hello.s, which is what I slowly changed into the
> program I submitted earlier (copied from
> <http://home.ptd.net/~tms2/hello.html>):
Ah, T. M. Sommers... I've heard of him! :) We'll probably get a better
answer (correcting my mistakes) from him...
> 1: .data # Data section
> 2:
> 3: msg: .asciz "Hello, world.\n" # The string to print.
> 4: len = . - msg - 1 # The length of the
> string.
Note that here, "len" is a "defined number" - it doesn't *have* an
address...
> 5:
> 5: .text # Code section.
> 6: .global _start
> 7:
> 8: _start: # Entry point.
> 10: pushl $len # Arg 3 to write: length
> of string.
> 11: pushl $msg # Arg 2: pointer to
> string.
> 12: pushl $1 # Arg 1: file descriptor.
> 13: movl $4, %eax # Write.
> 14: call do_syscall
> 15: addl $12, %esp # Clean stack.
Yeah, as I thought, BSD wants something much more like a C calling
convention (except for the syscall number in eax... %eax, I mean :)
> 16:
> 17: pushl $0 # Exit status.
> 18: movl $1, %eax # Exit.
> 19: call do_syscall
> 20:
> 21: do_syscall:
> 22: int $0x80 # Call kernel.
> 23: ret
So... simply translating Jonathan's example to Gas syntax isn't going to
work on BSD :( Probably not going to work without some corrections, but
here's an attempt to "wing it" based on your code:
.data # Data section
bufsize: .long 8192
.bss # Variables
.comm buf, 8192 # Reserve 8k
.text # Code section.
.global _start
_start: # Entry point.
popl %ebx # argc
popl %ebx # argv[0] program name
nextfile:
popl %ebx # argv[N] - a filename(?)
movl $5, %eax # the system call for open()
pushl $0 # O_RDONLY, defined in fcntl.h
pushl %ebx # filename in ebx
call do_syscall
addl $8, %esp # Clean stack.
# file descriptor in eax
test %eax, %eax # let's make sure it is valid
jns file_function # if the file descriptor does not have
# the
# sign flag ( which means it's
# less than 0 )
# jump to file_function
error:
pushl %eax # there was an error, push the errno
movl $1, %eax # put the exit syscall in eax
call do_syscall # bail out
# no point in cleaning stack :)
file_function:
pushl bufsize # we want *contents*!
# or pushl $8192
pushl $buf # address of buf
pushl %eax # sys_open returned file descriptor
# into eax
movl $3, %eax # sys_read
call do_syscall
addl $12, %esp # Clean stack.
test %eax, %eax # see what got returned
#jz nextfile # got an EOF, go to read the
# next file (not in this version)
jz exit # quit on EOF ?
js error # got an error, bail out
pushl %eax # the count of bytes
pushl $buf # address of buffer
pushl $1 # STDOUT file descriptor
movl $4, %eax # system call for write
call do_syscall
addl $12, %esp # Clean stack.
exit:
movl $1, %eax
pushl $0
call do_syscall # bail out
# no point in cleaning stack :)
do_syscall:
int $0x80 # Call kernel.
ret
That, if it works at all, will only do the first 8k of the file. If you
want to loop back and read more, you'll need to save the file descriptor
returned by sys_open - it wouldn't be in eax if we just looped back to
sys_read with this code. Shouldn't be hard to add that, or the
(commented out) jump back to read more filenames from the command-line.
Gotta leave something as an exercise for the reader - besides, I've
probably made enough errors already :)
Best,
Frank
- Previous message: Grumble: "Re: stack pointer part 2"
- In reply to: Ray: "Re: Help translating Intel to AT&T"
- Next in thread: Ray: "Re: Help translating Intel to AT&T"
- Reply: Ray: "Re: Help translating Intel to AT&T"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
