From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6116 invoked by alias); 14 Oct 2003 16:02:21 -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 6108 invoked from network); 14 Oct 2003 16:02:20 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 14 Oct 2003 16:02:20 -0000 Received: from drow by nevyn.them.org with local (Exim 4.24 #1 (Debian)) id 1A9Rcq-0002tc-BD; Tue, 14 Oct 2003 12:02:20 -0400 Date: Tue, 14 Oct 2003 16:02:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Cc: kettenis@gnu.org Subject: Re: problem unwinding past pthread_cond_wait() on x86 RedHat 9.0 Message-ID: <20031014160220.GA11076@nevyn.them.org> Mail-Followup-To: gdb-patches@sources.redhat.com, kettenis@gnu.org References: <20031014054225.GB919@gnat.com> <20031014125731.GA14097@nevyn.them.org> <20031014155810.GB989@gnat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031014155810.GB989@gnat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-10/txt/msg00459.txt.bz2 On Tue, Oct 14, 2003 at 08:58:10AM -0700, Joel Brobecker wrote: > > That's NPTL. Are you sure you understand the problem right - I don't > > have RH9's glibc here, only Rawhide's, but there's CFI for > > pthread_cond_wait in Rawhide. > > I can't say I'm 100% sure, but last time I checked, I couldn't find > any CFI: > > % objdump --headers /lib/tls/libpthread.so.0 | grep frame > 15 .eh_frame_hdr 0000002c 00009dc8 00009dc8 00009dc8 2**2 > 16 .eh_frame 0000010c 00009df4 00009df4 00009df4 2**2 > > No .debug_frame section (not a single dwarf2-related section for > that matter). That is CFI. The .eh_frame section is actually just about the same as the .debug_frame section, but encoded a little differently and loaded into memory instead of marked as a debugging section. However, 0x10c bytes is not encouraging for having unwind info for the function in question. In rawhide: 15 .eh_frame_hdr 000001d4 0000bf10 0000bf10 0000bf10 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 16 .eh_frame 00000944 0000c0e4 0000c0e4 0000c0e4 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA > > So anyway this _will_ go away someday. > > Yes, fortunately. I just suppose that the RH9.0 users will probably have > to update their NPTL library if they want this to work... > > > You really can't unwind past this sort of thing without either debug > > info or frame pointers. > > That was my feeling too. But having only a little experience in the > area, I was wondering if there was any technique that I didn't know > about. > > > 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? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer