From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6308 invoked by alias); 3 Dec 2004 02:43:23 -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 6265 invoked from network); 3 Dec 2004 02:43:17 -0000 Received: from unknown (HELO arwen.tausq.org) (64.81.244.109) by sourceware.org with SMTP; 3 Dec 2004 02:43:17 -0000 Received: by arwen.tausq.org (Postfix, from userid 1000) id B9618111F38; Thu, 2 Dec 2004 18:43:14 -0800 (PST) Date: Fri, 03 Dec 2004 02:43:00 -0000 From: Randolph Chung To: gdb-patches@sources.redhat.com Cc: brobecker@adacore.com Subject: Re: [RFC] Infinite backtraces... Message-ID: <20041203024314.GR6359@tausq.org> Reply-To: Randolph Chung Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041202231255.GM994@adacore.com> X-GPG: for GPG key, see http://www.tausq.org/gpg.txt User-Agent: Mutt/1.5.6+20040722i X-SW-Source: 2004-12/txt/msg00056.txt.bz2 > I am sort of walking on thin ice here, though. I could very well > imagine a case where we would rely on register value in one case, > and a flag from whatever frame information we find in another case. > This is why I'm mentioning this idea here. JIC. yeah, relying on return pointer register values seems a bit iffy. I suspect it might be zero in your case only by luck. on hppa-linux, for example: (gdb) bt #0 thread_function (arg=0x0) at /home/tausq/gdb/gdb-cvs/gdb/testsuite/gdb.threads/manythreads.c:32 #1 0x405ee4b8 in pthread_start_thread () from /lib/libpthread.so.0 #2 0x405ee540 in pthread_start_thread_event () from /lib/libpthread.so.0 #3 0x40878514 in clone () from /lib/libc.so.6 #4 0x40878514 in clone () from /lib/libc.so.6 Previous frame identical to this frame (corrupt stack?) so it terminates only because we are lucky... :( for hppa-linux, i believe the correct fix is to fix glibc so that the clone() procedure sets the "can't unwind" flag in the unwind record and then using a mechanism similar to what you proposed, we can stop the backtrace. in your particular case, i'm curious to know how we get from a pc=0 frame to a previous frame. that seems like a bug to me? i like the idea of a new method. perhaps the default implementation could be instead the "main" and "entry point" logic that's currently in the core frame code, and targets can overload and enhance this method accordingly? randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/