From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20858 invoked by alias); 7 Feb 2004 04:25:13 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 20851 invoked from network); 7 Feb 2004 04:25:12 -0000 Received: from unknown (HELO mwinf0504.wanadoo.fr) (193.252.22.26) by sources.redhat.com with SMTP; 7 Feb 2004 04:25:12 -0000 Received: from takamaka.act-europe.fr (AStDenis-103-1-3-27.w81-249.abo.wanadoo.fr [81.249.113.27]) by mwinf0504.wanadoo.fr (SMTP Server) with ESMTP id 0298F10003E0; Sat, 7 Feb 2004 05:25:11 +0100 (CET) Received: by takamaka.act-europe.fr (Postfix, from userid 507) id E5DE147D62; Sat, 7 Feb 2004 08:25:07 +0400 (RET) Date: Sat, 07 Feb 2004 04:25:00 -0000 From: Joel Brobecker To: David Carlton Cc: gdb Subject: Re: backtrace issues Message-ID: <20040207042507.GI18961@gnat.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-SW-Source: 2004-02/txt/msg00073.txt.bz2 > Actually, the fact that the program was compiled with a recent GCC > seems to be irrelevant. > > I did come up with a stripped-down test case; I've filed PR gdb/1545 > about it. Note that I have also reported a similar problem with the pthread_library. With 5.3, GDB was doing an approximate job, and lost a few frames in the way, but we still had the useful part of the backtrace more or less intact. With the new frame code, however, the unwinder just stops :-( and leaves the user with a bactracke which he can't use. Given the level of optimization involved in the code from which we wanted to backtrace from, it was determined that there was very little that we could do, which is unfortunate because it used to be able to get out of this quagmire before... At the time when we discussed this, we argued that the only hope was with dwarf2 CFI, but it just so happens that I noticed the exact same sort of problem on Windows XP (where we don't have dwarf-2 :-/). I have been brooding for a while over this, and really don't see any solution to this, right now. Maybe it's unfair to say this: I find the new frame code well structured and blissfully free of all the hacks we used to have. However, it seems less tolerant to difficult cases, where we just stop unwinding while we used to be able to have a useful backtrace with 5.3. (please don't see this as a complaint or don't think I am pointing finger at anybody - if I had found a better solution, believe me, I would have sent a suggestion). -- Joel