From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10347 invoked by alias); 15 Oct 2003 19:34:18 -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 10340 invoked from network); 15 Oct 2003 19:34:15 -0000 Received: from unknown (HELO walton.kettenis.dyndns.org) (213.93.115.144) by sources.redhat.com with SMTP; 15 Oct 2003 19:34:15 -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 h9FJXBlW000263; Wed, 15 Oct 2003 21:33:11 +0200 (CEST) (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 h9FJWuZ8000283; Wed, 15 Oct 2003 21:32:56 +0200 (CEST) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: (from kettenis@localhost) by elgar.kettenis.dyndns.org (8.12.6p3/8.12.6/Submit) id h9FJWZMc000278; Wed, 15 Oct 2003 21:32:35 +0200 (CEST) Date: Wed, 15 Oct 2003 19:34:00 -0000 Message-Id: <200310151932.h9FJWZMc000278@elgar.kettenis.dyndns.org> From: Mark Kettenis To: drow@mvista.com CC: gdb-patches@sources.redhat.com In-reply-to: <20031014160220.GA11076@nevyn.them.org> (message from Daniel Jacobowitz on Tue, 14 Oct 2003 12:02:20 -0400) Subject: Re: problem unwinding past pthread_cond_wait() on x86 RedHat 9.0 References: <20031014054225.GB919@gnat.com> <20031014125731.GA14097@nevyn.them.org> <20031014155810.GB989@gnat.com> <20031014160220.GA11076@nevyn.them.org> X-SW-Source: 2003-10/txt/msg00498.txt.bz2 Date: Tue, 14 Oct 2003 12:02:20 -0400 From: Daniel Jacobowitz > > How did it work in 5.3? I'm assuming dumb luck, we unwound 0xfffffe02 > > wrong. > > With 5.3, it was "luck", if we can call it that way (the old backtrace > is incomplete too, and probably the value of some registers is not > unwound properly in some of the frames). I didn't look too closely, but > I think GDB 5.3 didn't handle 0xfffffe02 as a frameless function, and > therefore used %ebp to fetch the return address. The problem is that > this %ebp was the frame pointer from a caller two or three frames up... > So we ended up skipping these two or three frames. And then after that, > it was business as usual... Ah, and pthread_cond_wait is frameless so that worked. Hmmmmm. If we get confused, falling back to trying %ebp wouldn't be an entirely bad idea. Mark, does that seem plausible or is it just asking for problems? It's tricky. The point is that the unwinder tries very hard not to get confused; only if it's certain that it has found code that sets up a frame it uses %ebp. Otherwise it assumes the function is frameless. If we don't do it like this, we'll certainly miss some frames in some fairly common cases, for example in many of the syscall stubs in glibc. Also note that for truly frameless code, %ebp can be used as a scratch register, and therefore can't be trusted to contain a valid frame pointer at all. Mark