This is the mail archive of the gdb-prs@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: exp/1656: if gdb cannot find function return value location, random unitialized value is used


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]