From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28757 invoked by alias); 9 Jan 2004 16:22:32 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 28401 invoked from network); 9 Jan 2004 16:22:29 -0000 Received: from unknown (HELO walton.kettenis.dyndns.org) (213.93.115.144) by sources.redhat.com with SMTP; 9 Jan 2004 16:22:29 -0000 Received: from elgar.kettenis.dyndns.org (elgar.kettenis.dyndns.org [192.168.0.2]) by walton.kettenis.dyndns.org (8.12.6p3/8.12.6) with ESMTP id i09GMSuN000408 for ; Fri, 9 Jan 2004 17:22:28 +0100 (CET) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: from elgar.kettenis.dyndns.org (localhost [127.0.0.1]) by elgar.kettenis.dyndns.org (8.12.6p3/8.12.6) with ESMTP id i09GMSfl000594 for ; Fri, 9 Jan 2004 17:22:28 +0100 (CET) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: (from kettenis@localhost) by elgar.kettenis.dyndns.org (8.12.6p3/8.12.6/Submit) id i09GMRVn000591; Fri, 9 Jan 2004 17:22:27 +0100 (CET) Date: Fri, 09 Jan 2004 16:22:00 -0000 Message-Id: <200401091622.i09GMRVn000591@elgar.kettenis.dyndns.org> From: Mark Kettenis To: gdb@sources.redhat.com Subject: [RFC] Struct return values X-SW-Source: 2004-01/txt/msg00123.txt.bz2 Recently Andrew did some work on structure return values. The result was that GDB now refuses to make a function return, that returns a struct accoriding to the "struct value" convention. The reasoning behind this is that in general, we can't determine the address of the bit of memory where we're supposed to return the value if we're in the middle of such a function. However, it turns out that with 32-bit SPARC, we can find out. The SPARC stack frames have a reserved slot for this address. Should we allow returning in this case? Furthermore, the testsuite contains the following comment: # The struct return case. Since any modification # would be by reference, and that can't happen, the # value should be unmodified and hence Z is expected. # Is this a reasonable assumption? I think the answer to the question is "no". It's perfectly allowed for the caller to provide a bit of scratch memory for the return value, and copy the contents of this bit of memory to the variable after the callee returns. Now if we return from a random point in the callee, the contents of the scratch memory will be undetermined, and some random bytes will be copied into the variable. This happens for code generated by the Sun compiler. A way to fix this, is to make sure that GDB stops immediately after we return from the callee. Is there an easy way to achieve this? Otherwise, I think we should refrain from checking the value in this case. Comments? Mark