From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4372 invoked by alias); 14 Oct 2003 15:58:14 -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 4363 invoked from network); 14 Oct 2003 15:58:11 -0000 Received: from unknown (HELO takamaka.act-europe.fr) (206.116.66.93) by sources.redhat.com with SMTP; 14 Oct 2003 15:58:11 -0000 Received: by takamaka.act-europe.fr (Postfix, from userid 507) id 9F9B3D2D29; Tue, 14 Oct 2003 08:58:10 -0700 (PDT) Date: Tue, 14 Oct 2003 15:58:00 -0000 From: Joel Brobecker To: gdb-patches@sources.redhat.com Subject: Re: problem unwinding past pthread_cond_wait() on x86 RedHat 9.0 Message-ID: <20031014155810.GB989@gnat.com> References: <20031014054225.GB919@gnat.com> <20031014125731.GA14097@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031014125731.GA14097@nevyn.them.org> User-Agent: Mutt/1.4i X-SW-Source: 2003-10/txt/msg00458.txt.bz2 > 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). > 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... -- Joel