Using labels as immediate operands in GAS with intel syntax

  • Follow


I have the following code for a hello world program for GAS:

..intel_syntax noprefix

..data					# section declaration

msg:	.ascii	"Hello, world!\n"	# our dear string
	len = . - msg			# length of our dear string

msg_p:	.int	msg
len_p:	.int	len

..text					# section declaration

			# we must export the entry point to the ELF linker or
    .global _start	# loader. They conventionally recognize _start as
their
			# entry point. Use ld -e foo to override the default.

_start:

# write our string to stdout

        mov     edx, [len_p]	#third argument: message length
        mov     ecx, [msg_p]	#second argument: pointer to message to
write
        mov     ebx, 1		#first argument: file handle (stdout)
        mov     eax, 4		#system call number (sys_write)
        int     0x80		#call kernel

# and exit

	mov	ebx, 0	   #first syscall argument: exit code
        mov     eax, 1     #system call number (sys_exit)
        int     0x80	   #call kernel




The problem is that is i use

        mov     ecx, msg	#second argument: pointer to message to write

to place the adress of the message in ecx, for some reason GAS takes
msg to be a memory adress and generates the code:

        mov     ecx, [msg]	#second argument: pointer to message to
write

Any one knows a away around this????


Paulo Lopes



0
Reply paulo.a.c.lopes (1) 11/12/2009 9:07:28 PM

Paulo wrote:
> I have the following code for a hello world program for GAS:
> 
> .intel_syntax noprefix
> 
> .data					# section declaration
> 
> msg:	.ascii	"Hello, world!\n"	# our dear string
> 	len = . - msg			# length of our dear string
> 
> msg_p:	.int	msg
> len_p:	.int	len
> 
> .text					# section declaration
> 
> 			# we must export the entry point to the ELF linker or
>     .global _start	# loader. They conventionally recognize _start as
> their
> 			# entry point. Use ld -e foo to override the default.
> 
> _start:
> 
> # write our string to stdout
> 
>         mov     edx, [len_p]	#third argument: message length
>         mov     ecx, [msg_p]	#second argument: pointer to message to
> write
>         mov     ebx, 1		#first argument: file handle (stdout)
>         mov     eax, 4		#system call number (sys_write)
>         int     0x80		#call kernel
> 
> # and exit
> 
> 	mov	ebx, 0	   #first syscall argument: exit code
>         mov     eax, 1     #system call number (sys_exit)
>         int     0x80	   #call kernel
> 
> 
> 
> 
> The problem is that is i use
> 
>         mov     ecx, msg	#second argument: pointer to message to write
> 
> to place the adress of the message in ecx, for some reason GAS takes
> msg to be a memory adress and generates the code:
> 
>         mov     ecx, [msg]	#second argument: pointer to message to
> write
> 
> Any one knows a away around this????

Without ".intel_syntax noprefix", "$msg". With ".intel_syntax", try 
"offset msg". If that doesn't work, try "offset flat: msg" (I think 
that's an old one).

Best,
Frank


0
Reply Frank 11/12/2009 9:46:59 PM


On 12 Nov, 21:46, Frank Kotler <fbkot...@MUNGED.microcosmotalk.com>
wrote:
> Paulo wrote:
> > I have the following code for a hello world program for GAS:
>
> > .intel_syntax noprefix
>
> > .data =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0# section declaration
>
> > msg: =A0 =A0 =A0 .ascii =A0"Hello, world!\n" =A0 =A0 # our dear string
> > =A0 =A0len =3D . - msg =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 # length of =
our dear string
>
> > msg_p: =A0 =A0 .int =A0 =A0msg
> > len_p: =A0 =A0 .int =A0 =A0len
>
> > .text =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0# section declaration
>
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# we must export the entry point=
 to the ELF linker or
> > =A0 =A0 .global _start # loader. They conventionally recognize _start a=
s
> > their
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# entry point. Use ld -e foo to =
override the default.
>
> > _start:
>
> > # write our string to stdout
>
> > =A0 =A0 =A0 =A0 mov =A0 =A0 edx, [len_p] =A0 =A0 =A0 #third argument: m=
essage length
> > =A0 =A0 =A0 =A0 mov =A0 =A0 ecx, [msg_p] =A0 =A0 =A0 #second argument: =
pointer to message to
> > write
> > =A0 =A0 =A0 =A0 mov =A0 =A0 ebx, 1 =A0 =A0 =A0 =A0 =A0 =A0 #first argum=
ent: file handle (stdout)
> > =A0 =A0 =A0 =A0 mov =A0 =A0 eax, 4 =A0 =A0 =A0 =A0 =A0 =A0 #system call=
 number (sys_write)
> > =A0 =A0 =A0 =A0 int =A0 =A0 0x80 =A0 =A0 =A0 =A0 =A0 =A0 =A0 #call kern=
el
>
> > # and exit
>
> > =A0 =A0mov =A0 =A0 ebx, 0 =A0 =A0 #first syscall argument: exit code
> > =A0 =A0 =A0 =A0 mov =A0 =A0 eax, 1 =A0 =A0 #system call number (sys_exi=
t)
> > =A0 =A0 =A0 =A0 int =A0 =A0 0x80 =A0 =A0 =A0 =A0 =A0#call kernel
>
> > The problem is that is i use
>
> > =A0 =A0 =A0 =A0 mov =A0 =A0 ecx, msg =A0 #second argument: pointer to m=
essage to write
>
> > to place the adress of the message in ecx, for some reason GAS takes
> > msg to be a memory adress and generates the code:
>
> > =A0 =A0 =A0 =A0 mov =A0 =A0 ecx, [msg] #second argument: pointer to mes=
sage to
> > write
>
> > Any one knows a away around this????
>
> Without ".intel_syntax noprefix", "$msg". With ".intel_syntax", try
> "offset msg". If that doesn't work, try "offset flat: msg" (I think
> that's an old one).
>
> Best,
> Frank- Ocultar texto citado -
>
> - Mostrar texto citado -

Nice!!! offset msg works, but can you tell me were is the
documentation for that?

Paulo Lopes
0
Reply Paulo 11/12/2009 10:55:33 PM

Paulo wrote:

....
> Nice!!! offset msg works, but can you tell me were is the
> documentation for that?

No. When ".intel_syntax" was a new thing, I discovered "offset flat:" by 
looking at the source code (not the recommended method!). I also found 
the name of the woman who wrote the code (Catherine Greene, IIRC), and 
wrote to her about documentation. She replied that she had "just reverse 
engineered some stuff" they got from Intel. There *may* be some 
documentation for it now, but I don't know where to find it. Sorry.

Best,
Frank


0
Reply Frank 11/12/2009 11:23:54 PM

3 Replies
242 Views

(page loaded in 0.058 seconds)

Similiar Articles:










7/23/2012 4:11:12 PM


Reply: