public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: c/9700: va_start gets __offset wrong in some situations
@ 2003-02-15 2:26 Aron Griffis
0 siblings, 0 replies; 6+ messages in thread
From: Aron Griffis @ 2003-02-15 2:26 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR c/9700; it has been noted by GNATS.
From: Aron Griffis <agriffis@gentoo.org>
To: bangerth@dealii.org, bjb@gentoo.org, gcc-bugs@gcc.gnu.org,
gcc-prs@gcc.gnu.org, msterret@coat.com, nobody@gcc.gnu.org,
wwoods@gentoo.org, gcc-gnats@gcc.gnu.org
Cc:
Subject: Re: c/9700: va_start gets __offset wrong in some situations
Date: Fri, 14 Feb 2003 21:28:13 -0500
bangerth@dealii.org wrote:[Fri Feb 14 2003, 09:10:12PM EST]
> Admittedly I only looked at the program given in the first
> report. So, let me ask again: I think that that program
> does exactly what should be expected, is this right? If so,
> the comment in that program about expectations is wrong.
Ah, this is where we're not communicating. The comment is accurate. I
can rephrase it as follows, perhaps this is more clear:
/*
* This is the first invocation of va_arg. The argument list is as
* follows:
*
* a = 0
* b = 0
* c = 0
* d = 0
* e = 0
* ap = { undef, undef }
* first_custom = "one"
* ... = "two", "three"
*
* Therefore va_arg should return "two". However in this example it
* erroneously returns "one", which is first_custom.
*/
> Second question: if the program in the first report doesn't
> show the problem at all, is it demonstrated in the second?
> If so, I'll be happy to take a look at that one on Monday.
It is demonstrated in both, but most clearly in the second, where __base
is clearly pointing 8-bytes prior to the correct location. It seems
like the alignment of __base in the single instance is being corrected
downward instead of upward.
Note you will need an Alpha to build the second example program since
the definition of va_list is different on x86. However it might not be
necessary since I've posted the output.
Aron
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: c/9700: va_start gets __offset wrong in some situations
@ 2003-02-15 2:36 Wolfgang Bangerth
0 siblings, 0 replies; 6+ messages in thread
From: Wolfgang Bangerth @ 2003-02-15 2:36 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR c/9700; it has been noted by GNATS.
From: Wolfgang Bangerth <bangerth@ticam.utexas.edu>
To: Aron Griffis <agriffis@gentoo.org>
Cc: bangerth@dealii.org, <bjb@gentoo.org>, <gcc-bugs@gcc.gnu.org>,
<msterret@coat.com>, <wwoods@gentoo.org>, <gcc-gnats@gcc.gnu.org>
Subject: Re: c/9700: va_start gets __offset wrong in some situations
Date: Fri, 14 Feb 2003 20:29:14 -0600 (CST)
On Fri, 14 Feb 2003, Aron Griffis wrote:
> bangerth@dealii.org wrote:[Fri Feb 14 2003, 09:10:12PM EST]
> > Admittedly I only looked at the program given in the first
> > report. So, let me ask again: I think that that program
> > does exactly what should be expected, is this right? If so,
> > the comment in that program about expectations is wrong.
>
> Ah, this is where we're not communicating. The comment is accurate. I
> can rephrase it as follows, perhaps this is more clear:
>
> /*
> * This is the first invocation of va_arg. The argument list is as
> * follows:
> *
> * a = 0
> * b = 0
> * c = 0
> * d = 0
> * e = 0
> * ap = { undef, undef }
> * first_custom = "one"
> * ... = "two", "three"
> *
> * Therefore va_arg should return "two". However in this example it
> * erroneously returns "one", which is first_custom.
> */
OK. It seems as if I misread it.
In any case, the program does as expected on my x86 linux machine. I can't
compile the second program on my machine, as you mention. So I assume that
this is something that is specific to the alpha port. I'll change the
synopsis accordingly, and leave this to the port maintainers.
Thanks for keeping me on track ;-)
Wolfgang
-------------------------------------------------------------------------
Wolfgang Bangerth email: bangerth@ticam.utexas.edu
www: http://www.ticam.utexas.edu/~bangerth/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: c/9700: va_start gets __offset wrong in some situations
@ 2003-02-15 2:10 bangerth
0 siblings, 0 replies; 6+ messages in thread
From: bangerth @ 2003-02-15 2:10 UTC (permalink / raw)
To: agriffis, bjb, gcc-bugs, gcc-prs, msterret, nobody, wwoods
Synopsis: va_start gets __offset wrong in some situations
State-Changed-From-To: closed->feedback
State-Changed-By: bangerth
State-Changed-When: Sat Feb 15 02:10:12 2003
State-Changed-Why:
Admittedly I only looked at the program given in the first
report. So, let me ask again: I think that that program
does exactly what should be expected, is this right? If so,
the comment in that program about expectations is wrong.
Second question: if the program in the first report doesn't
show the problem at all, is it demonstrated in the second?
If so, I'll be happy to take a look at that one on Monday.
W.
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9700
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: c/9700: va_start gets __offset wrong in some situations
@ 2003-02-15 1:56 Aron Griffis
0 siblings, 0 replies; 6+ messages in thread
From: Aron Griffis @ 2003-02-15 1:56 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR c/9700; it has been noted by GNATS.
From: Aron Griffis <agriffis@gentoo.org>
To: nobody@gcc.gnu.org, bjb@gentoo.org, gcc-gnats@gcc.gnu.org,
agriffis@gentoo.org, gcc-bugs@gcc.gnu.org, wwoods@gentoo.org,
msterret@coat.com, gcc-prs@gcc.gnu.org
Cc:
Subject: Re: c/9700: va_start gets __offset wrong in some situations
Date: Fri, 14 Feb 2003 20:58:29 -0500
Hi,
I realize you get a lot of bogus bug reports, but please take a closer
look at what I'm reporting. The problem here is when the argument list
is constructed in a certain way, then the first invocation of va_arg
will return the *last named argument* instead of the first unnamed
argument.
Regarding your simpler example, you're right, it returns a pointer to
"two" as is documented. In the more complex example I posted, va_arg
returns a pointer to "one" instead.
This problem exists on Alpha where the generic stdarg builtins are used.
I've run some tests on x86 and the problem doesn't appear.
Here is the output from the example program I posted in bug 9709. Sorry
I omitted it from the original bug report. In each function invocation
below, an additional char is prepended to the argument list. As you can
see, va_arg returns the wrong argument in only one situation. -1
immediately preceeds 999 in the argument list and is the last named
argument.
0: __base = 0x11ffff3f0 (999)
1: __base = 0x11ffff3f0 (999)
2: __base = 0x11ffff3f0 (999)
3: __base = 0x11ffff3f0 (999)
4: __base = 0x11ffff3f0 (999)
5: __base = 0x11ffff3e8 (-1) <<<<<<<<<<<<<
6: __base = 0x11ffff3f0 (999)
7: __base = 0x11ffff3f0 (999)
8: __base = 0x11ffff3f0 (999)
9: __base = 0x11ffff3f0 (999)
10: __base = 0x11ffff3f0 (999)
11: __base = 0x11ffff3f0 (999)
12: __base = 0x11ffff3f0 (999)
13: __base = 0x11ffff3f0 (999)
14: __base = 0x11ffff3f0 (999)
15: __base = 0x11ffff3f0 (999)
16: __base = 0x11ffff3f0 (999)
17: __base = 0x11ffff3f0 (999)
18: __base = 0x11ffff3f0 (999)
19: __base = 0x11ffff3f0 (999)
20: __base = 0x11ffff3f0 (999)
21: __base = 0x11ffff3f0 (999)
22: __base = 0x11ffff3f0 (999)
23: __base = 0x11ffff3f0 (999)
24: __base = 0x11ffff3f0 (999)
25: __base = 0x11ffff3f0 (999)
26: __base = 0x11ffff3f0 (999)
27: __base = 0x11ffff3f0 (999)
28: __base = 0x11ffff3f0 (999)
29: __base = 0x11ffff3f0 (999)
30: __base = 0x11ffff3f0 (999)
31: __base = 0x11ffff3f0 (999)
32: __base = 0x11ffff3f0 (999)
33: __base = 0x11ffff3f0 (999)
34: __base = 0x11ffff3f0 (999)
35: __base = 0x11ffff3f0 (999)
36: __base = 0x11ffff3f0 (999)
37: __base = 0x11ffff3f0 (999)
38: __base = 0x11ffff3f0 (999)
39: __base = 0x11ffff3f0 (999)
As it turns out, the above run demonstrates that the problem is
somewhere in setting up the __base pointer, not in the calculation of
__offset as I originally thought.
Thanks,
Aron
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: c/9700: va_start gets __offset wrong in some situations
@ 2003-02-15 0:14 bangerth
0 siblings, 0 replies; 6+ messages in thread
From: bangerth @ 2003-02-15 0:14 UTC (permalink / raw)
To: agriffis, bjb, gcc-bugs, gcc-prs, msterret, nobody, wwoods
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1199 bytes --]
Synopsis: va_start gets __offset wrong in some situations
State-Changed-From-To: open->closed
State-Changed-By: bangerth
State-Changed-When: Sat Feb 15 00:14:24 2003
State-Changed-Why:
Not a bug. The man page says:
The first use of the va_arg macro after that of the
va_start macro returns the argument after last. Succes
sive invocations return the values of the remaining argu
ments.
You also get the "two" from this small example:
#include <stdarg.h>
void func(const char *first_custom,
...)
{
char *s;
va_list custom_args;
va_start (custom_args, first_custom);
s = va_arg(custom_args, char *);
printf ("%s\n", s);
va_end (custom_args);
}
int main() {
func("one", "two", "three");
}
(also on Linux). Given the description on the man page,
this is not surprising.
W.
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9700
^ permalink raw reply [flat|nested] 6+ messages in thread
* c/9700: va_start gets __offset wrong in some situations
@ 2003-02-14 5:26 agriffis
0 siblings, 0 replies; 6+ messages in thread
From: agriffis @ 2003-02-14 5:26 UTC (permalink / raw)
To: gcc-gnats; +Cc: bjb, wwoods, msterret
>Number: 9700
>Category: c
>Synopsis: va_start gets __offset wrong in some situations
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: unassigned
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Fri Feb 14 05:26:00 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator: Aron Griffis
>Release: 3.2.2
>Organization:
>Environment:
Reading specs from /usr/lib/gcc-lib/alpha-unknown-linux-gnu/3.2.2/specs
Configured with: /usr/local/tmp/portage/gcc-3.2.2/work/gcc-3.2.2/configure --prefix=/usr --bindir=/usr/alpha-unknown-linux-gnu/gcc-bin/3.2 --includedir=/usr/lib/gcc-lib/alpha-unknown-linux-gnu/3.2.2/include --datadir=/usr/share/gcc-data/alpha-unknown-linux-gnu/3.2 --mandir=/usr/share/gcc-data/alpha-unknown-linux-gnu/3.2/man --infodir=/usr/share/gcc-data/alpha-unknown-linux-gnu/3.2/info --enable-shared --host=alpha-unknown-linux-gnu --target=alpha-unknown-linux-gnu --with-system-zlib --enable-languages=c,c++,ada,f77,objc,java --enable-threads=posix --enable-long-long --disable-checking --enable-cstdio=stdio --enable-clocale=generic --enable-__cxa_atexit --enable-version-specific-runtime-libs --with-gxx-include-dir=/usr/lib/gcc-lib/alpha-unknown-linux-gnu/3.2.2/include/g++-v3 --with-local-prefix=/usr/local --enable-shared --enable-nls --without-included-gettext
Thread model: posix
gcc version 3.2.2
This is an Alpha EV67 (XP1000).
>Description:
Found this while porting Gnome 2.2 to Alpha. It appears that in some situations, va_start() sets up __offset to point to the last *named* argument instead of the first *unnamed* argument.
The bug is completely repeatable. Note that I'm intentionally passing a va_list structure in the arguments to the function, that's not an accident. It seems like the stack needs to be setup just right for this to occur.
The symptoms are the same with or without optimization enabled.
>How-To-Repeat:
#include <stdarg.h>
void func(char *a,
char *b,
char *c,
char *d,
char *e,
va_list ap,
const char *first_custom,
...)
{
va_list custom_args;
char *s;
if (first_custom) {
va_start (custom_args, first_custom);
/*
* Here we call va_arg and expect to get a
* pointer to "two";
* instead we get a pointer to "one".
*/
s = va_arg(custom_args, char *);
printf ("%s\n", s);
va_end (custom_args);
}
}
int main() {
va_list ap;
func(0, 0, 0, 0, 0, ap, "one", "two", "three");
}
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: application/octet-stream; name="va_start.i"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="va_start.i"
IyAxICJ2YV9zdGFydC5jIgojIDEgIjxidWlsdC1pbj4iCiMgMSAiPGNvbW1hbmQgbGluZT4iCiMg
MSAidmFfc3RhcnQuYyIKIyAxICIvdXNyL2xpYi9nY2MtbGliL2FscGhhLXVua25vd24tbGludXgt
Z251LzMuMi4yL2luY2x1ZGUvc3RkYXJnLmgiIDEgMwojIDQzICIvdXNyL2xpYi9nY2MtbGliL2Fs
cGhhLXVua25vd24tbGludXgtZ251LzMuMi4yL2luY2x1ZGUvc3RkYXJnLmgiIDMKdHlwZWRlZiBf
X2J1aWx0aW5fdmFfbGlzdCBfX2dudWNfdmFfbGlzdDsKIyAxMTAgIi91c3IvbGliL2djYy1saWIv
YWxwaGEtdW5rbm93bi1saW51eC1nbnUvMy4yLjIvaW5jbHVkZS9zdGRhcmcuaCIgMwp0eXBlZGVm
IF9fZ251Y192YV9saXN0IHZhX2xpc3Q7CiMgMiAidmFfc3RhcnQuYyIgMgoKdm9pZCBmdW5jKGNo
YXIgKmEsCiAgICAgICAgICBjaGFyICpiLAogICAgICAgICAgY2hhciAqYywKICAgICAgICAgIGNo
YXIgKmQsCiAgICAgICAgICBjaGFyICplLAogICAgICAgICAgdmFfbGlzdCBhcCwKICAgICAgICAg
IGNvbnN0IGNoYXIgKmZpcnN0X2N1c3RvbSwKICAgICAgICAgIC4uLikKewogICAgdmFfbGlzdCBj
dXN0b21fYXJnczsKICAgIGNoYXIgKnM7CiAgICBpZiAoZmlyc3RfY3VzdG9tKSB7CiAgICAgICAg
X19idWlsdGluX3N0ZGFyZ19zdGFydCgoY3VzdG9tX2FyZ3MpLGZpcnN0X2N1c3RvbSk7CgoKCgoK
ICAgICAgICBzID0gX19idWlsdGluX3ZhX2FyZyhjdXN0b21fYXJncywgY2hhciAqKTsKICAgICAg
ICBwcmludGYgKCIlc1xuIiwgcyk7CgogICAgICAgIF9fYnVpbHRpbl92YV9lbmQgKGN1c3RvbV9h
cmdzKTsKICAgIH0KfQoKaW50IG1haW4oKSB7CiAgICB2YV9saXN0IGFwOwogICAgZnVuYygwLCAw
LCAwLCAwLCAwLCBhcCwgIm9uZSIsICJ0d28iLCAidGhyZWUiKTsKfQo=
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2003-02-15 2:36 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-02-15 2:26 c/9700: va_start gets __offset wrong in some situations Aron Griffis
-- strict thread matches above, loose matches on Subject: below --
2003-02-15 2:36 Wolfgang Bangerth
2003-02-15 2:10 bangerth
2003-02-15 1:56 Aron Griffis
2003-02-15 0:14 bangerth
2003-02-14 5:26 agriffis
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).