From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32258 invoked by alias); 15 Oct 2009 18:06:05 -0000 Received: (qmail 32246 invoked by uid 22791); 15 Oct 2009 18:06:05 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from shell4.bayarea.net (HELO shell4.bayarea.net) (209.128.82.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 15 Oct 2009 18:05:58 +0000 Received: (qmail 18684 invoked from network); 15 Oct 2009 11:05:56 -0700 Received: from 209-128-106-254.bayarea.net (HELO redwood.eagercon.com) (209.128.106.254) by shell4.bayarea.net with SMTP; 15 Oct 2009 11:05:55 -0700 Message-ID: <4AD7647E.30806@eagercon.com> Date: Thu, 15 Oct 2009 18:06:00 -0000 From: Michael Eager User-Agent: Thunderbird 2.0.0.23 (X11/20090825) MIME-Version: 1.0 To: Joel Brobecker CC: tromey@redhat.com, "gdb-patches@sourceware.org" Subject: Re: [PATCH] Support for Xilinx MicroBlaze References: <4AD74E86.1020500@eagercon.com> <4AD757FE.6060704@eagercon.com> <20091015171755.GD5272@adacore.com> In-Reply-To: <20091015171755.GD5272@adacore.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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/msg00350.txt.bz2 Joel Brobecker wrote: >> 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. There's no other compiler for MicroBlaze. (I was going to mention this hypothetical situation, but this has very low probability of ever being a real concern.) > 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. It's not so much that GCC is unwilling to fix the problem. If I wanted to, I could extend the CIE generation code and modify the MicroBlaze-specific code in both GCC and GDB. This would break debugging existing programs and libraries with the new gdb as well as break debugging newly compiled code with an old gdb. (There are ways that this might be synchronized with Xilinx's release of tool chains to their customers, but I'd be very reluctant to recommend that a new tool chain be incompatible with older tool chains unless there was a very compelling reason.) If anyone can suggest a reasonable way to identify whether the CIE entry for return address is lr or lr+offset, I'll pursue making gdb accept both. This is certainly clear while parsing the CIE, but it is particularly ugly to put a target-dependent test in this code. -- Michael Eager eager@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077