This is the mail archive of the
gdb-prs@sources.redhat.com
mailing list for the GDB project.
Re: exp/1656: if gdb cannot find function return value location, random unitialized value is used
- From: Mark Kettenis <kettenis at chello dot nl>
- To: nobody at sources dot redhat dot com
- Cc: gdb-prs at sources dot redhat dot com,
- Date: 24 May 2004 07:58:01 -0000
- Subject: Re: exp/1656: if gdb cannot find function return value location, random unitialized value is used
- Reply-to: Mark Kettenis <kettenis at chello dot nl>
The following reply was made to PR exp/1656; it has been noted by GNATS.
From: Mark Kettenis <kettenis@chello.nl>
To: gdb-gnats@sources.redhat.com
Cc: mec.gnu@mindspring.com, cagney@redhat.com
Subject: Re: exp/1656: if gdb cannot find function return value location, random unitialized value is used
Date: Mon, 24 May 2004 09:50:47 +0200 (CEST)
Date: 23 May 2004 14:33:38 -0000
From: mec.gnu@mindspring.com
Consider this source code from gdb.base/structs.c:
zed ();
L1 = fun1();
With pre-merge gcc HEAD, the generated code looks like this:
push &L1
call fun1
With post-merge gcc HEAD, the generated code looks like this:
push &tmp
call fun1
L1 = tmp
But that's suboptimal; it introduces an extra copy. Anyway, the Sun
compiler on SPARC generates code similar to post-merge GCC. Actually
this is the behaviour described by many ABIs, although most ABIs
explicitly allow the pre-merge GCC behaviour.
With the pre-merge gcc HEAD, suppressing the return value means
that the old value is left in L1. gdb.base/structs.exp is prepared
for this to happen.
This is a bogus assumption. Andrew argued that the assumption was
true for GCC and that the test was catching real bugs. Seems to be no
longer true.
(1) Add some doco like this for the "return" command:
"Sometimes, gdb does not know where the return value of a function
is located. This is more likely to happen if the return value is
an aggregate value such as a structure value. If this happens, gdb
will ask you whether you want to continue forcing the function to
return. If you do continue, the function return value may be
undefined or random".
Seems adequate. On OpenBSD/m68k a `long double' is returned in
memory, so scalars may suffer from the same problem.
(2) Add another line to the warning from gdb that the return value
may be undefined or random.
Yes please.
(3) Enhance structs.exp so that if gdb emits this warning,
structs.exp does not expect any specific value at all for the
return value.
Yes please.