From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19726 invoked by alias); 15 Oct 2009 17:18:16 -0000 Received: (qmail 19712 invoked by uid 22791); 15 Oct 2009 17:18:14 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 15 Oct 2009 17:18:08 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id C80F82BAC96; Thu, 15 Oct 2009 13:18:06 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 5w7Ogzbl-lmE; Thu, 15 Oct 2009 13:18:06 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 86F392BAC35; Thu, 15 Oct 2009 13:18:06 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 7FF21F58A0; Thu, 15 Oct 2009 10:17:55 -0700 (PDT) Date: Thu, 15 Oct 2009 17:18:00 -0000 From: Joel Brobecker To: Michael Eager Cc: tromey@redhat.com, "gdb-patches@sourceware.org" Subject: Re: [PATCH] Support for Xilinx MicroBlaze Message-ID: <20091015171755.GD5272@adacore.com> References: <4AD74E86.1020500@eagercon.com> <4AD757FE.6060704@eagercon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AD757FE.6060704@eagercon.com> User-Agent: Mutt/1.5.18 (2008-05-17) Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-10/txt/msg00345.txt.bz2 > I'm just as happy to leave this problem unfixed. Gcc generates an > incorrect CIE entry, which is philosophically not a good thing. > But fixing this causes far more problems than it solves. One of the things that we perhaps didn't consider is debugging code compiled with a compiler other than GCC... Not sure if one even exists, though, but that compiler might be generating correct debugging info, which would trigger the "bug" in GDB. Anyway, if "GCC" is unwilling to fix the problem, then GDB has to do its best. It's disappointing when that happens, but it's not the first time we introduce work-arounds. This one is a little harder to accept because it causes GDB to malfunction in case of correct debugging info. But it's still better this way, in practice. -- Joel