Forgetting return values

Forgetting return values

[Jamie Prescott]

What am I missing?
I have a simple:

static inline int set_prop(char const *path, char const *name,
                                          void const *data, int size)
{
        int error;

        asm volatile ("int\t11\n\t"
                      : "=a0" (error): "a0" (path), "a1" (name), "a2" (data),
                        "a3" (size));

        return error;
}

extern int calc(int);

int proc(int i)
{
        int j = calc(i);

        return set_prop(0, 0, &j, sizeof(int));
}

The aX classes maps to the rX registers, no problem for GCC in there.
The code above, compiled with GCC 4.4.0 and -O3 produces:


 _proc:
        push    FP
        mov     SP,FP
        sub     SP,4,SP
        call   _calc
        mov     0,r0
        mov     4,r3
        add     FP,-4,r2
        mov     r0,r1
;       APP
; 69 "xxxx.c" 1
        int     11
        
;       NO_APP
        add     SP,4,SP
        pop     FP
        ret

GCC forgets about the calc() return value, and passes an address (FP-4) that
has never been written into.
buf if I add a "memory" clobber to the asm inline, everything comes back to
normal:

_proc:
        push    FP
        mov     SP,FP
        sub     SP,4,SP
        call   _calc
        str.w    r0,FP[-4]
        mov     0,r0
        mov     4,r3
        add     FP,-4,r2
        mov     r0,r1
;       APP
; 69 "xxxx.c" 1
        int     11
        
;       NO_APP
        add     SP,4,SP
        pop     FP
        ret

Why is the memory clobber required, and why GCC does not understand to
sync the value to memory when passing the address to a function?
Thanks,


- Jamie



      

Re: Forgetting return values

[Adam Nemet]

Jamie Prescott <jpresss@yahoo.com> writes:
> static inline int set_prop(char const *path, char const *name,
>                                           void const *data, int size)
> {
>         int error;
>
>         asm volatile ("int\t11\n\t"
>                       : "=a0" (error): "a0" (path), "a1" (name), "a2" (data),
>                         "a3" (size));
>
>         return error;
> }
>
> extern int calc(int);
>
> int proc(int i)
> {
>         int j = calc(i);
>
>         return set_prop(0, 0, &j, sizeof(int));
> }
...
>
> Why is the memory clobber required, and why GCC does not understand to
> sync the value to memory when passing the address to a function?

Because you never inform GCC that you will use the value at
address *NAME.  Try to use "m"(*name) rather than "a1"(name) in the asm.

Adam

Re: Forgetting return values

[Jamie Prescott]

> From: Adam Nemet <anemet@caviumnetworks.com>
> To: Jamie Prescott <jpresss@yahoo.com>
> Cc: gcc@gcc.gnu.org
> Sent: Thursday, May 28, 2009 11:10:49 AM
> Subject: Re: Forgetting return values
> 
> Jamie Prescott writes:
> > static inline int set_prop(char const *path, char const *name,
> >                                           void const *data, int size)
> > {
> >         int error;
> >
> >         asm volatile ("int\t11\n\t"
> >                       : "=a0" (error): "a0" (path), "a1" (name), "a2" (data),
> >                         "a3" (size));
> >
> >         return error;
> > }
> >
> > extern int calc(int);
> >
> > int proc(int i)
> > {
> >         int j = calc(i);
> >
> >         return set_prop(0, 0, &j, sizeof(int));
> > }
> ...
> >
> > Why is the memory clobber required, and why GCC does not understand to
> > sync the value to memory when passing the address to a function?
> 
> Because you never inform GCC that you will use the value at
> address *NAME.  Try to use "m"(*name) rather than "a1"(name) in the asm.

That's 'data', not 'name'. But OK, got it. unfortunately, I cannot use "m" since
that value need to go into a specific register.
Any other solution?


- Jamie


      

Re: Forgetting return values

[Adam Nemet]

Jamie Prescott writes:
> > From: Adam Nemet <anemet@caviumnetworks.com>
> > Jamie Prescott writes:
> > > static inline int set_prop(char const *path, char const *name,
> > >                                           void const *data, int size)
> > > {
> > >         int error;
> > >
> > >         asm volatile ("int\t11\n\t"
> > >                       : "=a0" (error): "a0" (path), "a1" (name), "a2" (data),
> > >                         "a3" (size));
> > >
> > >         return error;
> > > }
> > >
> > > extern int calc(int);
> > >
> > > int proc(int i)
> > > {
> > >         int j = calc(i);
> > >
> > >         return set_prop(0, 0, &j, sizeof(int));
> > > }
> > ...
> > >
> > > Why is the memory clobber required, and why GCC does not understand to
> > > sync the value to memory when passing the address to a function?
> > 
> > Because you never inform GCC that you will use the value at
> > address *NAME.  Try to use "m"(*name) rather than "a1"(name) in the asm.
> 
> That's 'data', not 'name'. But OK, got it. unfortunately, I cannot use "m" since
> that value need to go into a specific register.
> Any other solution?

You can also have it *in addition* as an argument to the asm that's never
used:

        asm volatile ("int\t11\n\t"
                      : "=a0" (error): "a0" (path), "a1" (name), "a2" (data),
                        "a3" (size), "m"(*data));

after changing data's type into something that can be dereferenced.

Adam

Re: Forgetting return values

[Jamie Prescott]

> From: Andrew Haley <aph@redhat.com>
> To: Jamie Prescott <jpresss@yahoo.com>
> Cc: Adam Nemet <anemet@caviumnetworks.com>; "gcc-help@gcc.gnu.org" <gcc-help@gcc.gnu.org>
> Sent: Thursday, May 28, 2009 11:48:30 AM
> Subject: Re: Forgetting return values
> 
> Jamie Prescott wrote:
> >> From: Adam Nemet 
> 
> >>> Why is the memory clobber required, and why GCC does not understand to
> >>> sync the value to memory when passing the address to a function?
> >> Because you never inform GCC that you will use the value at
> >> address *NAME.  Try to use "m"(*name) rather than "a1"(name) in the asm.
> > 
> > That's 'data', not 'name'. But OK, got it. unfortunately, I cannot use "m" 
> since
> > that value need to go into a specific register.
> 
> This is not appropriate for gcc@, which is for gcc development.

Sorry, I posted to gcc@ because I thought it was a problem with my TARGET.


- Jamie