From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1570 invoked by alias); 21 Apr 2006 13:36:45 -0000 Received: (qmail 1560 invoked by uid 22791); 21 Apr 2006 13:36:44 -0000 X-Spam-Check-By: sourceware.org Received: from mta09-winn.ispmail.ntl.com (HELO mtaout03-winn.ispmail.ntl.com) (81.103.221.49) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 21 Apr 2006 13:36:41 +0000 Received: from aamtaout02-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout03-winn.ispmail.ntl.com with ESMTP id <20060421133638.QPGK27969.mtaout03-winn.ispmail.ntl.com@aamtaout02-winn.ispmail.ntl.com> for ; Fri, 21 Apr 2006 14:36:38 +0100 Received: from zapata.pink ([82.6.101.32]) by aamtaout02-winn.ispmail.ntl.com with ESMTP id <20060421133638.KTBP24467.aamtaout02-winn.ispmail.ntl.com@zapata.pink> for ; Fri, 21 Apr 2006 14:36:38 +0100 Received: from zapata.pink (localhost.localdomain [127.0.0.1]) by zapata.pink (8.13.1/8.13.1) with ESMTP id k3LDaKPf012486; Fri, 21 Apr 2006 14:36:21 +0100 Received: (from aph@localhost) by zapata.pink (8.13.1/8.13.1/Submit) id k3LDaKYF012483; Fri, 21 Apr 2006 14:36:20 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17480.57300.323193.19108@zapata.pink> Date: Fri, 21 Apr 2006 13:36:00 -0000 From: "Andrew Haley" To: "Thibaud GUERIN" Cc: gcc-help@gcc.gnu.org Subject: Re: Fwd: error in variable dereferencing In-Reply-To: <96d59a150604200925hc168909rdc50fd22160d26a8@mail.gmail.com> References: <96d59a150604200353h6249fa1fr8a93d20baff37fc5@mail.gmail.com> <96d59a150604200657m53252a12t601302ec580f44b7@mail.gmail.com> <17479.38716.774167.250676@zapata.pink> <96d59a150604200737r1287348o1abb6e90e3fdc381@mail.gmail.com> <17479.43930.922063.971387@zapata.pink> <96d59a150604200858sa31ac6brd5cf87387b452fc4@mail.gmail.com> <96d59a150604200901lf97810sef1a79043a680b58@mail.gmail.com> <17479.45849.787868.917095@zapata.pink> <96d59a150604200925hc168909rdc50fd22160d26a8@mail.gmail.com> X-Mailer: VM 7.19 under Emacs 21.3.1 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2006-04/txt/msg00225.txt.bz2 Thibaud GUERIN writes: > On 4/21/06, Andrew Haley wrote: > > Thibaud GUERIN writes: > > > On 4/20/06, Andrew Haley 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.