Re: Fwd: error in variable dereferencing

Re: Fwd: error in variable dereferencing

[Thibaud GUERIN]

On 4/20/06, Andrew Haley <aph@gcc.gnu.org> wrote:
> Thibaud GUERIN writes:
>  > hi,
>  > I'm actually writing a program in C and i'm fighting with an address
>  > dereferencing since some days now.
>  >
>  > int            the_bug(const char *fmt, ...)
>  > {
>  >   char    **ap;
>  >   char        **s = (char **)(&fmt);
>  >
>  > /* __asm__ volatile ( */
>  > /*           "\tleal %1, %%eax\n" */
>  > /*           "\tmovl %%eax,%0\n" */
>  > /*           "\tmovl %1, %%eax\n" */
>  > /*           "\tmovl %2, %%ebx \n" */
>  > /*           "\tmovl %%eax, (%%ebx)\n" */
>  > /*           : "=m"(ap) : "m" (fmt), "m"(ap)); */
>
> This is wrong in so many ways I don't know where to start.
>
> It may be better if you try to tell us what you are trying to do.
>
> Redirecting gcc-help@gcc.gnu.org.


Not clear in the first message, (and maybe not in this one too..), sorry


This asm inline was something like a "test/patch code".

I try to have a simple :

char        **ap = (char **)(&fmt);

working, It didn't :
ap was equal to &fmt BUT *ap wasn't equal to fmt (don't kown why...)

so i try by my self... to do :

ap = &fmt;
*ap = fmt;

in asm inline.... (dirty i know...)

problem is :
With this asm code in the binary *s is equal to fmt
Without this asm code in the binary *s isn't equal to fmt


All the 's' variable stuffs are from my debug...
Again :
My only aim is to have an 'ap = &fmt' valid (->ap = &fmt AND *ap = fmt)

The resulting asm was here to help you to understand wath's wrong ....
I'm looking for some days now without answer...

--
Thibaud

Re: error in variable dereferencing

[Thibaud GUERIN]

Just realise i didn't  put refference to my 1st post... so it may be a
little confuse....
please read :
http://gcc.gnu.org/ml/gcc/2006-04/msg00414.html
for more infos/the full 1st message

Of course a lot of time :
char ** = &(char *)
works, it's a C basic code...
but not in my "special" use :(


--
Thibaud

Re: Fwd: error in variable dereferencing

[Andrew Haley]

Thibaud GUERIN writes:
 > On 4/20/06, Andrew Haley <aph@gcc.gnu.org> wrote:
 > > Thibaud GUERIN writes:
 > >  > hi,
 > >  > I'm actually writing a program in C and i'm fighting with an address
 > >  > dereferencing since some days now.
 > >  >
 > >  > int            the_bug(const char *fmt, ...)
 > >  > {
 > >  >   char    **ap;
 > >  >   char        **s = (char **)(&fmt);
 > >  >
 > >  > /* __asm__ volatile ( */
 > >  > /*           "\tleal %1, %%eax\n" */
 > >  > /*           "\tmovl %%eax,%0\n" */
 > >  > /*           "\tmovl %1, %%eax\n" */
 > >  > /*           "\tmovl %2, %%ebx \n" */
 > >  > /*           "\tmovl %%eax, (%%ebx)\n" */
 > >  > /*           : "=m"(ap) : "m" (fmt), "m"(ap)); */
 > >
 > > This is wrong in so many ways I don't know where to start.
 > >
 > > It may be better if you try to tell us what you are trying to do.
 > >
 > > Redirecting gcc-help@gcc.gnu.org.
 > 
 > 
 > Not clear in the first message, (and maybe not in this one too..), sorry
 > 
 > 
 > This asm inline was something like a "test/patch code".
 > 
 > I try to have a simple :
 > 
 > char        **ap = (char **)(&fmt);

I don't think that's legal.  (Actually, I'm not perfectly sure it's
not legal, but I think not.)  Also, I have no idea why you're trying
to do such a thing.

 > working, It didn't :
 > ap was equal to &fmt BUT *ap wasn't equal to fmt (don't kown why...)

I'm sure that's impossible.  :-)

 > so i try by my self... to do :
 > 
 > ap = &fmt;
 > *ap = fmt;
 > 
 > in asm inline.... (dirty i know...)
 > 
 > problem is :
 > With this asm code in the binary *s is equal to fmt
 > Without this asm code in the binary *s isn't equal to fmt
 > 
 > 
 > All the 's' variable stuffs are from my debug...
 > Again :
 > My only aim is to have an 'ap = &fmt' valid (->ap = &fmt AND *ap = fmt)

So why not do the obvious 

  const char **ap = &fmt ;

?

 > The resulting asm was here to help you to understand wath's wrong ....
 > I'm looking for some days now without answer...

You're still not explaining yourself.  You have a const char* arg that
you are trying to alter, but instead of doing it the obvious way with
an assignment, you're taking the address of the arg, casting the
resulting pointer to a different pointer type, and then overwriting
the arg through the resulting pointer.

What's the point of all this?

Andrew.

Re: Fwd: error in variable dereferencing

[Thibaud GUERIN]

On 4/20/06, Andrew Haley <aph@redhat.com> wrote:
> Thibaud GUERIN writes:
>  >
>  >
>  > Not clear in the first message, (and maybe not in this one too..), sorry
>  >
>  >
>  > This asm inline was something like a "test/patch code".
>  >
>  > I try to have a simple :
>  >
>  > char        **ap = (char **)(&fmt);
>
> I don't think that's legal.  (Actually, I'm not perfectly sure it's
> not legal, but I think not.)  Also, I have no idea why you're trying
> to do such a thing.

as i'm compiling with :
-Wall -Werror -nostdinc -Wstrict-aliasing=2
it will not compile if it wasn't (i think, not sure too...)

>
>  > working, It didn't :
>  > ap was equal to &fmt BUT *ap wasn't equal to fmt (don't kown why...)
>
> I'm sure that's impossible.  :-)

it wasn't belive me... and it's driving me crasy since days....

>  > so i try by my self... to do :
>  >
>  > ap = &fmt;
>  > *ap = fmt;
>  >
>  > in asm inline.... (dirty i know...)
>  >
>  > problem is :
>  > With this asm code in the binary *s is equal to fmt
>  > Without this asm code in the binary *s isn't equal to fmt
>  >
>  >
>  > All the 's' variable stuffs are from my debug...
>  > Again :
>  > My only aim is to have an 'ap = &fmt' valid (->ap = &fmt AND *ap = fmt)
>
> So why not do the obvious
>
>   const char **ap = &fmt ;
>
> ?

because i need to do some :
ap++;
to get the next args in stack, as my end aim is to do re-write a printf...

>
>  > The resulting asm was here to help you to understand wath's wrong ....
>  > I'm looking for some days now without answer...
>
> You're still not explaining yourself.  You have a const char* arg that
> you are trying to alter, but instead of doing it the obvious way with
> an assignment, you're taking the address of the arg, casting the
> resulting pointer to a different pointer type, and then overwriting
> the arg through the resulting pointer.
>
> What's the point of all this?
>

i'm not trying to alter an (const char*) but to get the args in my
stack by getting some pointers on it, as in all va_args fonctions....


An thing i forgot (shame on me) : in my VM, i ork with segmented memory, ....
but i don't think that make the trick as all variavles are on stack in
this code (exepte the 'fmt' in the parent function, but it's address
is pushed in stack for the call so....)

the call in the parent is something like :

int parent ()
{
the_bug("string1", "string2", "string 3");
}

--
Thibaud

Re: Fwd: error in variable dereferencing

[Andrew Haley]

Thibaud GUERIN writes:
 > On 4/20/06, Andrew Haley <aph@redhat.com> wrote:
 > > Thibaud GUERIN writes:
 > >  >
 > >  >
 > >  > Not clear in the first message, (and maybe not in this one too..), sorry
 > >  >
 > >  >
 > >  > This asm inline was something like a "test/patch code".
 > >  >
 > >  > I try to have a simple :
 > >  >
 > >  > char        **ap = (char **)(&fmt);
 > >
 > > I don't think that's legal.  (Actually, I'm not perfectly sure it's
 > > not legal, but I think not.)  Also, I have no idea why you're trying
 > > to do such a thing.
 > 
 > as i'm compiling with :
 > -Wall -Werror -nostdinc -Wstrict-aliasing=2
 > it will not compile if it wasn't (i think, not sure too...)

That is not true.  We don't gurantee to generate an error for all
invalid source.

 > >  > working, It didn't :
 > >  > ap was equal to &fmt BUT *ap wasn't equal to fmt (don't kown why...)
 > >
 > > I'm sure that's impossible.  :-)
 > 
 > it wasn't belive me... and it's driving me crasy since days....
 > 
 > >  > so i try by my self... to do :
 > >  >
 > >  > ap = &fmt;
 > >  > *ap = fmt;
 > >  >
 > >  > in asm inline.... (dirty i know...)
 > >  >
 > >  > problem is :
 > >  > With this asm code in the binary *s is equal to fmt
 > >  > Without this asm code in the binary *s isn't equal to fmt
 > >  >
 > >  >
 > >  > All the 's' variable stuffs are from my debug...
 > >  > Again :
 > >  > My only aim is to have an 'ap = &fmt' valid (->ap = &fmt AND *ap = fmt)
 > >
 > > So why not do the obvious
 > >
 > >   const char **ap = &fmt ;
 > >
 > > ?
 > 
 > because i need to do some :
 > ap++;
 > to get the next args in stack, as my end aim is to do re-write a printf...

So why not use va_list?  That's what va_list is for.

 > >  > The resulting asm was here to help you to understand wath's wrong ....
 > >  > I'm looking for some days now without answer...
 > >
 > > You're still not explaining yourself.  You have a const char* arg that
 > > you are trying to alter, but instead of doing it the obvious way with
 > > an assignment, you're taking the address of the arg, casting the
 > > resulting pointer to a different pointer type, and then overwriting
 > > the arg through the resulting pointer.
 > >
 > > What's the point of all this?
 > 
 > i'm not trying to alter an (const char*) but to get the args in my
 > stack by getting some pointers on it, as in all va_args fonctions....

Trying to do all this stuff behind the compiler's back is likely to
break things.  Use va_list.

Andrew.

Re: Fwd: error in variable dereferencing

[Thibaud GUERIN]

On 4/21/06, Andrew Haley <aph@gcc.gnu.org> wrote:
> Thibaud GUERIN writes:
>  > On 4/20/06, Andrew Haley <aph@redhat.com> wrote:
>  > > Thibaud GUERIN writes:
>  > >  >
>  > >  >
>  > >  > Not clear in the first message, (and maybe not in this one too..), sorry
>  > >  >
>  > >  >
>  > >  > This asm inline was something like a "test/patch code".
>  > >  >
>  > >  > I try to have a simple :
>  > >  >
>  > >  > char        **ap = (char **)(&fmt);
>  > >
>  > > I don't think that's legal.  (Actually, I'm not perfectly sure it's
>  > > not legal, but I think not.)  Also, I have no idea why you're trying
>  > > to do such a thing.
>  >
>  > as i'm compiling with :
>  > -Wall -Werror -nostdinc -Wstrict-aliasing=2
>  > it will not compile if it wasn't (i think, not sure too...)
>
> That is not true.  We don't gurantee to generate an error for all
> invalid source.
>
>  > >  > working, It didn't :
>  > >  > ap was equal to &fmt BUT *ap wasn't equal to fmt (don't kown why...)
>  > >
>  > > I'm sure that's impossible.  :-)
>  >
>  > it wasn't belive me... and it's driving me crasy since days....
>  >
>  > >  > so i try by my self... to do :
>  > >  >
>  > >  > ap = &fmt;
>  > >  > *ap = fmt;
>  > >  >
>  > >  > in asm inline.... (dirty i know...)
>  > >  >
>  > >  > problem is :
>  > >  > With this asm code in the binary *s is equal to fmt
>  > >  > Without this asm code in the binary *s isn't equal to fmt
>  > >  >
>  > >  >
>  > >  > All the 's' variable stuffs are from my debug...
>  > >  > Again :
>  > >  > My only aim is to have an 'ap = &fmt' valid (->ap = &fmt AND *ap = fmt)
>  > >
>  > > So why not do the obvious
>  > >
>  > >   const char **ap = &fmt ;
>  > >
>  > > ?
>  >
>  > because i need to do some :
>  > ap++;
>  > to get the next args in stack, as my end aim is to do re-write a printf...
>
> So why not use va_list?  That's what va_list is for.
>
>  > >  > The resulting asm was here to help you to understand wath's wrong ....
>  > >  > I'm looking for some days now without answer...
>  > >
>  > > You're still not explaining yourself.  You have a const char* arg that
>  > > you are trying to alter, but instead of doing it the obvious way with
>  > > an assignment, you're taking the address of the arg, casting the
>  > > resulting pointer to a different pointer type, and then overwriting
>  > > the arg through the resulting pointer.
>  > >
>  > > What's the point of all this?
>  >
>  > i'm not trying to alter an (const char*) but to get the args in my
>  > stack by getting some pointers on it, as in all va_args fonctions....
>
> Trying to do all this stuff behind the compiler's back is likely to
> break things.  Use va_list.
>
> Andrew.
>

quote :
I'm compiling with (to run on my VM):
-std=gnu99 -Wall -Werror -nostdinc -Wstrict-aliasing=2 -fno-builtin 
-I../include -I../

no-builtin ....

I'm doing that because the va_list wasn't working too... (i come to
that dirty code by simplifing the code to found the root of the
problem)

And my final aim is to have a printf without any deps form any parent
system (no use of standard includes, ....)

--
Thibaud

Re: Fwd: error in variable dereferencing

[Andrew Haley]

Thibaud GUERIN writes:
 > On 4/21/06, Andrew Haley <aph@gcc.gnu.org> wrote:
 > > Thibaud GUERIN writes:
 > >  > On 4/20/06, Andrew Haley <aph@redhat.com> wrote:
 > >  > > Thibaud GUERIN writes:
 > >  > >  >
 > >  > >  >
 > >  > >  > Not clear in the first message, (and maybe not in this one too..), sorry
 > >  > >  >
 > >  > >  >
 > >  > >  > This asm inline was something like a "test/patch code".
 > >  > >  >
 > >  > >  > I try to have a simple :
 > >  > >  >
 > >  > >  > char        **ap = (char **)(&fmt);
 > >  > >
 > >  > >  > so i try by my self... to do :
 > >  > >  >
 > >  > >  > ap = &fmt;
 > >  > >  > *ap = fmt;
 > >  > >  >
 > >  > >  > in asm inline.... (dirty i know...)
 > >  > >  >
 > >  > >  > problem is :
 > >  > >  > With this asm code in the binary *s is equal to fmt
 > >  > >  > Without this asm code in the binary *s isn't equal to fmt
 > >  > >  >
 > >  > >  >
 > >  > >  > All the 's' variable stuffs are from my debug...
 > >  > >  > Again :
 > >  > >  > My only aim is to have an 'ap = &fmt' valid (->ap = &fmt AND *ap = fmt)
 > >  > >
 > >  > > So why not do the obvious
 > >  > >
 > >  > >   const char **ap = &fmt ;
 > >  > >
 > >  > > ?
 > >  >
 > >  > because i need to do some :
 > >  > ap++;
 > >  > to get the next args in stack, as my end aim is to do re-write a printf...
 > >
 > > So why not use va_list?  That's what va_list is for.
 > >
 > >  > >  > The resulting asm was here to help you to understand wath's wrong ....
 > >  > >  > I'm looking for some days now without answer...
 > >  > >
 > >  > > You're still not explaining yourself.  You have a const char* arg that
 > >  > > you are trying to alter, but instead of doing it the obvious way with
 > >  > > an assignment, you're taking the address of the arg, casting the
 > >  > > resulting pointer to a different pointer type, and then overwriting
 > >  > > the arg through the resulting pointer.
 > >  > >
 > >  > > What's the point of all this?
 > >  >
 > >  > i'm not trying to alter an (const char*) but to get the args in my
 > >  > stack by getting some pointers on it, as in all va_args fonctions....
 > >
 > > Trying to do all this stuff behind the compiler's back is likely to
 > > break things.  Use va_list.
 > 
 > quote :
 > I'm compiling with (to run on my VM):
 > -std=gnu99 -Wall -Werror -nostdinc -Wstrict-aliasing=2 -fno-builtin 
 > -I../include -I../
 > 
 > no-builtin ....
 > 
 > I'm doing that because the va_list wasn't working too... (i come to
 > that dirty code by simplifing the code to found the root of the
 > problem)

OK, so now I know what you're _really_ trying to do.  It took some
work, but we're here now.

 > And my final aim is to have a printf without any deps form any parent
 > system (no use of standard includes, ....)

Fair enough.  va_list and its friends can't be written in C, which is
why gcc provides builtin functions for them.  The standard ones look
like this:

#define va_start(v,l) __builtin_va_start(v,l)
#define va_end(v) __builtin_va_end(v)
#define va_arg(v,l) __builtin_va_arg(v,l)
#define va_copy(d,s) __builtin_va_copy(d,s)

Now, if you know absolutely for sure that your args are pushed onto
the stack in order without any holes, you might be able to get around
this.

void pkludge (char *s, ...) __attribute__((noinline));
void pkludge (char *s, ...)
{
  void **p = &s;
  printf ("%d\n", *(int *)++p);
  printf ("%d\n", *(int *)++p);
}

This isn't legal C, though, and trying to do things like this behind
gcc's back is asking for trouble.  The _real_ solution is to find out
why gcc's builtins are not working.

Andrew.

Re: Fwd: error in variable dereferencing

[Thibaud GUERIN]

On 4/21/06, Andrew Haley <aph@gcc.gnu.org> wrote:
> Thibaud GUERIN writes:
>  > On 4/21/06, Andrew Haley <aph@gcc.gnu.org> wrote:
>  > > Thibaud GUERIN writes:
>  > >  > On 4/20/06, Andrew Haley <aph@redhat.com> wrote:
>  > >  > > Thibaud GUERIN writes:
>  > >  > >  >
>  > >  > >  >
>  > >  > >  > Not clear in the first message, (and maybe not in this one too..), sorry
>  > >  > >  >
>  > >  > >  >
>  > >  > >  > This asm inline was something like a "test/patch code".
>  > >  > >  >
>  > >  > >  > I try to have a simple :
>  > >  > >  >
>  > >  > >  > char        **ap = (char **)(&fmt);
>  > >  > >
>  > >  > >  > so i try by my self... to do :
>  > >  > >  >
>  > >  > >  > ap = &fmt;
>  > >  > >  > *ap = fmt;
>  > >  > >  >
>  > >  > >  > in asm inline.... (dirty i know...)
>  > >  > >  >
>  > >  > >  > problem is :
>  > >  > >  > With this asm code in the binary *s is equal to fmt
>  > >  > >  > Without this asm code in the binary *s isn't equal to fmt
>  > >  > >  >
>  > >  > >  >
>  > >  > >  > All the 's' variable stuffs are from my debug...
>  > >  > >  > Again :
>  > >  > >  > My only aim is to have an 'ap = &fmt' valid (->ap = &fmt AND *ap = fmt)
>  > >  > >
>  > >  > > So why not do the obvious
>  > >  > >
>  > >  > >   const char **ap = &fmt ;
>  > >  > >
>  > >  > > ?
>  > >  >
>  > >  > because i need to do some :
>  > >  > ap++;
>  > >  > to get the next args in stack, as my end aim is to do re-write a printf...
>  > >
>  > > So why not use va_list?  That's what va_list is for.
>  > >
>  > >  > >  > The resulting asm was here to help you to understand wath's wrong ....
>  > >  > >  > I'm looking for some days now without answer...
>  > >  > >
>  > >  > > You're still not explaining yourself.  You have a const char* arg that
>  > >  > > you are trying to alter, but instead of doing it the obvious way with
>  > >  > > an assignment, you're taking the address of the arg, casting the
>  > >  > > resulting pointer to a different pointer type, and then overwriting
>  > >  > > the arg through the resulting pointer.
>  > >  > >
>  > >  > > What's the point of all this?
>  > >  >
>  > >  > i'm not trying to alter an (const char*) but to get the args in my
>  > >  > stack by getting some pointers on it, as in all va_args fonctions....
>  > >
>  > > Trying to do all this stuff behind the compiler's back is likely to
>  > > break things.  Use va_list.
>  >
>  > quote :
>  > I'm compiling with (to run on my VM):
>  > -std=gnu99 -Wall -Werror -nostdinc -Wstrict-aliasing=2 -fno-builtin
>  > -I../include -I../
>  >
>  > no-builtin ....
>  >
>  > I'm doing that because the va_list wasn't working too... (i come to
>  > that dirty code by simplifing the code to found the root of the
>  > problem)
>
> OK, so now I know what you're _really_ trying to do.  It took some
> work, but we're here now.
>
>  > And my final aim is to have a printf without any deps form any parent
>  > system (no use of standard includes, ....)
>
> Fair enough.  va_list and its friends can't be written in C, which is
> why gcc provides builtin functions for them.  The standard ones look
> like this:
>
> #define va_start(v,l) __builtin_va_start(v,l)
> #define va_end(v) __builtin_va_end(v)
> #define va_arg(v,l) __builtin_va_arg(v,l)
> #define va_copy(d,s) __builtin_va_copy(d,s)
>
> Now, if you know absolutely for sure that your args are pushed onto
> the stack in order without any holes, you might be able to get around
> this.
>
> void pkludge (char *s, ...) __attribute__((noinline));
> void pkludge (char *s, ...)
> {
>   void **p = &s;
>   printf ("%d\n", *(int *)++p);
>   printf ("%d\n", *(int *)++p);
> }
>
> This isn't legal C, though, and trying to do things like this behind
> gcc's back is asking for trouble.  The _real_ solution is to find out
> why gcc's builtins are not working.
>

Thanks for all the tips (maybe REALLY usefull later).

But my problem right now is that :

int			my_own_printf(char *fmt, ...)
{
  char		**s = (char **)(&fmt);

 if (*s == fmt)
   write(1, "they are the same\n", 18);
 else
   write(1, "they aren't the same\n", 21);
  return (0);
}

prints "they aren't the same" ....

so it seems there is a real problem...
for the memory :
building with :gcc-3.4.6 -std=gnu99 -Wall -nostdinc
-Wstrict-aliasing=2 -fno-builtin
running on a multi segmented environnement (in a qemu VM).

i'm always trying to make it work on my own env (or crash in my linux
box) without success...

--
Thibaud

Re: Fwd: error in variable dereferencing

[Andrew Haley]

Thibaud GUERIN writes:
 > >
 > > Now, if you know absolutely for sure that your args are pushed onto
 > > the stack in order without any holes, you might be able to get around
 > > this.
 > >
 > > void pkludge (char *s, ...) __attribute__((noinline));
 > > void pkludge (char *s, ...)
 > > {
 > >   void **p = &s;
 > >   printf ("%d\n", *(int *)++p);
 > >   printf ("%d\n", *(int *)++p);
 > > }
 > >
 > > This isn't legal C, though, and trying to do things like this behind
 > > gcc's back is asking for trouble.  The _real_ solution is to find out
 > > why gcc's builtins are not working.
 > >
 > 
 > Thanks for all the tips (maybe REALLY usefull later).
 > 
 > But my problem right now is that :
 > 
 > int			my_own_printf(char *fmt, ...)
 > {
 >   char		**s = (char **)(&fmt);
 > 
 >  if (*s == fmt)
 >    write(1, "they are the same\n", 18);
 >  else
 >    write(1, "they aren't the same\n", 21);
 >   return (0);
 > }
 > 
 > prints "they aren't the same" ....

OK, so we've got rid of the asms and casting away const, and the code
still doesn't work.

So, your code is now, at last, legal C.  Let's have a look at the
assembly code generated for my_own_printf (use gcc -S).  Be sure to
include the exact command line you used.

Andrew.

Re: Fwd: error in variable dereferencing

[Thibaud GUERIN]

On 4/21/06, Andrew Haley <aph@gcc.gnu.org> wrote:
> Thibaud GUERIN writes:
>  > >
>  > > Now, if you know absolutely for sure that your args are pushed onto
>  > > the stack in order without any holes, you might be able to get around
>  > > this.
>  > >
>  > > void pkludge (char *s, ...) __attribute__((noinline));
>  > > void pkludge (char *s, ...)
>  > > {
>  > >   void **p = &s;
>  > >   printf ("%d\n", *(int *)++p);
>  > >   printf ("%d\n", *(int *)++p);
>  > > }
>  > >
>  > > This isn't legal C, though, and trying to do things like this behind
>  > > gcc's back is asking for trouble.  The _real_ solution is to find out
>  > > why gcc's builtins are not working.
>  > >
>  >
>  > Thanks for all the tips (maybe REALLY usefull later).
>  >
>  > But my problem right now is that :
>  >
>  > int                  my_own_printf(char *fmt, ...)
>  > {
>  >   char               **s = (char **)(&fmt);
>  >
>  >  if (*s == fmt)
>  >    write(1, "they are the same\n", 18);
>  >  else
>  >    write(1, "they aren't the same\n", 21);
>  >   return (0);
>  > }
>  >
>  > prints "they aren't the same" ....
>
> OK, so we've got rid of the asms and casting away const, and the code
> still doesn't work.
>
> So, your code is now, at last, legal C.  Let's have a look at the
> assembly code generated for my_own_printf (use gcc -S).  Be sure to
> include the exact command line you used.
>

(my_own_printf is in the test_suites.c) :

gcc -c -o test_suites.o test_suites.c -std=gnu99 -Wall -nostdinc
-Wstrict-aliasing=2 -S -fno-builtin  -I../include -I../
give me :

(snip)

.LC0:
	.string	"they are the same\n"
.LC1:
	.string	"they aren't the same\n"
	.text
.globl my_own_printf
	.type	my_own_printf, @function
my_own_printf:
	pushl	%ebp
	movl	%esp, %ebp
	subl	$8, %esp
	leal	8(%ebp), %eax
	movl	%eax, -4(%ebp)
	movl	-4(%ebp), %eax
	movl	(%eax), %eax
	cmpl	8(%ebp), %eax
	jne	.L33
	subl	$4, %esp
	pushl	$18
	pushl	$.LC0
	pushl	$1
	call	write
	addl	$16, %esp
	jmp	.L34
.L33:
	subl	$4, %esp
	pushl	$21
	pushl	$.LC1
	pushl	$1
	call	write
	addl	$16, %esp
.L34:
	movl	$0, %eax
	leave
	ret
	.size	my_own_printf, .-my_own_printf
	.section	.rodata
.LC2:
	.string	"string2"
.LC3:
	.string	"string1"
	.text

(snip)


--
Thibaud

Re: Fwd: error in variable dereferencing

[Andrew Haley]

Thibaud GUERIN writes:
 > On 4/21/06, Andrew Haley <aph@gcc.gnu.org> wrote:
 > > Thibaud GUERIN writes:
 > >  > >
 > >
 > > OK, so we've got rid of the asms and casting away const, and the code
 > > still doesn't work.
 > >
 > > So, your code is now, at last, legal C.  Let's have a look at the
 > > assembly code generated for my_own_printf (use gcc -S).  Be sure to
 > > include the exact command line you used.

 > my_own_printf:

Args are just below sp.

 > 	pushl	%ebp
 > 	movl	%esp, %ebp

ebp points to:  frame, retaddr, arg0

 > 	subl	$8, %esp
 > 	leal	8(%ebp), %eax

eax contains ebp+8: it points to arg0

 > 	movl	%eax, -4(%ebp)

save eax on the stack

 > 	movl	-4(%ebp), %eax

restore it

 > 	movl	(%eax), %eax

load eax from arg0

 > 	cmpl	8(%ebp), %eax

compare eax with the memory at ebp+8

 > 	jne	.L33

So, the memory word at ebp+8 is compared with the memory at ebp+8.

Do you have a debuuger that can single-step through this code, one
insn at a time?

Andrew.

Re: Fwd: error in variable dereferencing

[Thibaud GUERIN]

On 4/22/06, Andrew Haley <aph@gcc.gnu.org> wrote:
> Thibaud GUERIN writes:
>  > On 4/21/06, Andrew Haley <aph@gcc.gnu.org> wrote:
>  > > Thibaud GUERIN writes:
>  > >  > >
>  > >
>  > > OK, so we've got rid of the asms and casting away const, and the code
>  > > still doesn't work.
>  > >
>  > > So, your code is now, at last, legal C.  Let's have a look at the
>  > > assembly code generated for my_own_printf (use gcc -S).  Be sure to
>  > > include the exact command line you used.
>
>  > my_own_printf:
>
> Args are just below sp.
>
>  >      pushl   %ebp
>  >      movl    %esp, %ebp
>
> ebp points to:  frame, retaddr, arg0
>
>  >      subl    $8, %esp
>  >      leal    8(%ebp), %eax
>
> eax contains ebp+8: it points to arg0
>
>  >      movl    %eax, -4(%ebp)
>
> save eax on the stack
>
>  >      movl    -4(%ebp), %eax
>
> restore it
>
>  >      movl    (%eax), %eax
>
> load eax from arg0
>
>  >      cmpl    8(%ebp), %eax
>
> compare eax with the memory at ebp+8
>
>  >      jne     .L33
>
> So, the memory word at ebp+8 is compared with the memory at ebp+8.
>
> Do you have a debuuger that can single-step through this code, one
> insn at a time?

Sorry no debugger... this is a part of the 1st program running (well
... trying to run)

The only debug ways usable in the code right now are some things like :
i = (long)(fmt);
__asm__ volatile ("mov %0, %%eax\n":: "m"(i));
__asm__ volatile ("l1: jmp l1");

which are really dirty i agree...

--
Thibaud

Re: Fwd: error in variable dereferencing

[Andrew Haley]

Thibaud GUERIN writes:
 > On 4/22/06, Andrew Haley <aph@gcc.gnu.org> wrote:
 > > Thibaud GUERIN writes:
 > >  > On 4/21/06, Andrew Haley <aph@gcc.gnu.org> wrote:
 > >  > > Thibaud GUERIN writes:
 > >  > >  > >
 > >  > >
 > >  > > OK, so we've got rid of the asms and casting away const, and the code
 > >  > > still doesn't work.
 > >  > >
 > >  > > So, your code is now, at last, legal C.  Let's have a look at the
 > >  > > assembly code generated for my_own_printf (use gcc -S).  Be sure to
 > >  > > include the exact command line you used.
 > >
 > >  > my_own_printf:
 > >
 > > Args are just below sp.
 > >
 > >  >      pushl   %ebp
 > >  >      movl    %esp, %ebp
 > >
 > > ebp points to:  frame, retaddr, arg0
 > >
 > >  >      subl    $8, %esp
 > >  >      leal    8(%ebp), %eax
 > >
 > > eax contains ebp+8: it points to arg0
 > >
 > >  >      movl    %eax, -4(%ebp)
 > >
 > > save eax on the stack
 > >
 > >  >      movl    -4(%ebp), %eax
 > >
 > > restore it
 > >
 > >  >      movl    (%eax), %eax
 > >
 > > load eax from arg0
 > >
 > >  >      cmpl    8(%ebp), %eax
 > >
 > > compare eax with the memory at ebp+8
 > >
 > >  >      jne     .L33
 > >
 > > So, the memory word at ebp+8 is compared with the memory at ebp+8.
 > >
 > > Do you have a debuuger that can single-step through this code, one
 > > insn at a time?
 > 
 > Sorry no debugger... this is a part of the 1st program running (well
 > ... trying to run)

Well, we've established that whetever is wrong, it's not the code gcc
generates for this routine.  It's correct, as you can see.

 > The only debug ways usable in the code right now are some things like :
 > i = (long)(fmt);
 > __asm__ volatile ("mov %0, %%eax\n":: "m"(i));
 > __asm__ volatile ("l1: jmp l1");
 > 
 > which are really dirty i agree...

Thay're also wrong, becasue they don't clobber eax.

Andrew.

Re: Fwd: error in variable dereferencing

[Thibaud GUERIN]

On 4/22/06, Andrew Haley <aph@redhat.com> wrote:
> Well, we've established that whetever is wrong, it's not the code gcc
> generates for this routine.  It's correct, as you can see.
>
>  > The only debug ways usable in the code right now are some things like :
>  > i = (long)(fmt);
>  > __asm__ volatile ("mov %0, %%eax\n":: "m"(i));
>  > __asm__ volatile ("l1: jmp l1");
>  >
>  > which are really dirty i agree...
>
> Thay're also wrong, becasue they don't clobber eax.

If you have any way to do it (or check with cleaner ways) i'm
listening .... it'll be helpfull....

--
Thibaud

Re: Fwd: error in variable dereferencing

[Andrew Haley]

Thibaud GUERIN writes:
 > On 4/22/06, Andrew Haley <aph@redhat.com> wrote:
 > > Well, we've established that whetever is wrong, it's not the code gcc
 > > generates for this routine.  It's correct, as you can see.
 > >
 > >  > The only debug ways usable in the code right now are some things like :
 > >  > i = (long)(fmt);
 > >  > __asm__ volatile ("mov %0, %%eax\n":: "m"(i));
 > >  > __asm__ volatile ("l1: jmp l1");
 > >  >
 > >  > which are really dirty i agree...
 > >
 > > Thay're also wrong, becasue they don't clobber eax.
 > 
 > If you have any way to do it (or check with cleaner ways) i'm
 > listening .... it'll be helpfull....

Just put "eax" in the clobber list of the asm.  But really, we've gone
as far down the read as we can with this: the gcc code you produced is
correct.  Time to look elsewhere.

Andrew.

Re: Fwd: error in variable dereferencing

[Thibaud GUERIN]

On 4/22/06, Andrew Haley <aph@gcc.gnu.org> wrote:
> Thibaud GUERIN writes:
>  > On 4/22/06, Andrew Haley <aph@redhat.com> wrote:
>  > > Well, we've established that whetever is wrong, it's not the code gcc
>  > > generates for this routine.  It's correct, as you can see.
>  > >
>  > >  > The only debug ways usable in the code right now are some things like :
>  > >  > i = (long)(fmt);
>  > >  > __asm__ volatile ("mov %0, %%eax\n":: "m"(i));
>  > >  > __asm__ volatile ("l1: jmp l1");
>  > >  >
>  > >  > which are really dirty i agree...
>  > >
>  > > Thay're also wrong, becasue they don't clobber eax.
>  >
>  > If you have any way to do it (or check with cleaner ways) i'm
>  > listening .... it'll be helpfull....
>
> Just put "eax" in the clobber list of the asm.  But really, we've gone
> as far down the read as we can with this: the gcc code you produced is
> correct.  Time to look elsewhere.
>

Yeah, i think too,
i learned a lot (-S flag, ....)
thanks for everything and sorry for disturbance....

--
Thibaud

Re: Fwd: error in variable dereferencing

[Andrew Haley]

Thibaud GUERIN writes:
 > On 4/22/06, Andrew Haley <aph@gcc.gnu.org> wrote:
 > > Thibaud GUERIN writes:
 > >  > On 4/22/06, Andrew Haley <aph@redhat.com> wrote:
 > >  > > Well, we've established that whetever is wrong, it's not the code gcc
 > >  > > generates for this routine.  It's correct, as you can see.
 > >  > >
 > >  > >  > The only debug ways usable in the code right now are some things like :
 > >  > >  > i = (long)(fmt);
 > >  > >  > __asm__ volatile ("mov %0, %%eax\n":: "m"(i));
 > >  > >  > __asm__ volatile ("l1: jmp l1");
 > >  > >  >
 > >  > >  > which are really dirty i agree...
 > >  > >
 > >  > > Thay're also wrong, becasue they don't clobber eax.
 > >  >
 > >  > If you have any way to do it (or check with cleaner ways) i'm
 > >  > listening .... it'll be helpfull....
 > >
 > > Just put "eax" in the clobber list of the asm.  But really, we've gone
 > > as far down the read as we can with this: the gcc code you produced is
 > > correct.  Time to look elsewhere.
 > 
 > Yeah, i think too,
 > i learned a lot (-S flag, ....)
 > thanks for everything and sorry for disturbance....

Don't apologize -- you did nothing wrong.  This is a help list, and
you asked for help.  That's OK.

Andrew.