From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4539 invoked by alias); 21 Jan 2002 16:29:16 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 4506 invoked from network); 21 Jan 2002 16:29:16 -0000 Received: from unknown (HELO cygnus.com) (205.180.230.5) by sources.redhat.com with SMTP; 21 Jan 2002 16:29:16 -0000 Received: from redhat.com (rtl.sfbay.redhat.com [205.180.230.21]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id IAA07267; Mon, 21 Jan 2002 08:29:13 -0800 (PST) Message-ID: <3C4C41BE.CAB374D7@redhat.com> Date: Mon, 21 Jan 2002 08:29:00 -0000 From: Fernando Nasser Organization: Red Hat Canada X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-13 i686) X-Accept-Language: en MIME-Version: 1.0 To: Jim Blandy CC: gdb-patches@sources.redhat.com Subject: Re: RFA: try to ensure abort has valid return address References: <20020112064706.52E575E9D8@zwingli.cygnus.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-01/txt/msg00645.txt.bz2 I wonder if we will always be able to trick the compiler with this, but it is worthy of a try. Approved. Thanks Jim. Fernando Jim Blandy wrote: > > 2002-01-12 Jim Blandy > > * gdb.base/coremaker.c (func2): Try to arrange for the return > address passed to `abort' to fall within `func2', so we can get > backtraces. > > Index: gdb/testsuite/gdb.base/coremaker.c > =================================================================== > RCS file: /cvs/cvsfiles/devo/gdb/testsuite/gdb.base/coremaker.c,v > retrieving revision 1.4 > diff -c -r1.4 coremaker.c > *** gdb/testsuite/gdb.base/coremaker.c 1999/06/25 23:44:28 1.4 > --- gdb/testsuite/gdb.base/coremaker.c 2002/01/12 06:42:09 > *************** > *** 81,87 **** > } > > void > ! func2 () > { > int coremaker_local[5]; > int i; > --- 81,87 ---- > } > > void > ! func2 (int please_abort) > { > int coremaker_local[5]; > int i; > *************** > *** 104,116 **** > for (i = 0; i < 5; i++) > coremaker_bss += coremaker_local[i]; > coremaker_data = coremaker_ro + 1; > ! abort (); > } > > void > func1 () > { > ! func2 (); > } > > int main () > --- 104,138 ---- > for (i = 0; i < 5; i++) > coremaker_bss += coremaker_local[i]; > coremaker_data = coremaker_ro + 1; > ! > ! /* This function used to simply call `abort' unconditionally. > ! However, because GCC sometimes knows that `abort' will never > ! return, the `call' instruction that invokes `abort' would > ! sometimes be the very last instruction in this function. The > ! epilogue instructions you'd normally expect --- deallocating the > ! frame, jumping to the return address --- were omitted, since > ! they'd never be reached anyway. This means that the return > ! address passed to abort (which it'll never use) actually points > ! beyond the end of the caller! Sometimes the return address > ! seemed to be in the next function; sometimes it seemed to be in > ! padding instructions between functions, for which there was no > ! line number info. In any case, GDB had difficulties producing a > ! backtrace in this case. > ! > ! There's no way to force the compiler not to put the call to > ! `abort' at the very end of the function --- after all, it is > ! functionally correct to do so. But we hope that putting it in a > ! conditional will make it more likely that GDB can get a > ! backtrace, and find coremaker_local, which is what we really care > ! about. */ > ! if (please_abort) > ! abort (); > } > > void > func1 () > { > ! func2 (1); > } > > int main () -- Fernando Nasser Red Hat Canada Ltd. E-Mail: fnasser@redhat.com 2323 Yonge Street, Suite #300 Toronto, Ontario M4P 2C9