From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19125 invoked by alias); 14 Oct 2009 17:49:35 -0000 Received: (qmail 19102 invoked by uid 22791); 14 Oct 2009 17:49:34 -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; Wed, 14 Oct 2009 17:49:29 +0000 Received: (qmail 20892 invoked from network); 14 Oct 2009 10:49:27 -0700 Received: from 209-128-106-254.bayarea.net (HELO redwood.eagercon.com) (209.128.106.254) by shell4.bayarea.net with SMTP; 14 Oct 2009 10:49:22 -0700 Message-ID: <4AD60F09.6020607@eagercon.com> Date: Wed, 14 Oct 2009 17:49:00 -0000 From: Michael Eager User-Agent: Thunderbird 2.0.0.23 (X11/20090825) MIME-Version: 1.0 To: Joel Brobecker CC: "gdb-patches@sourceware.org" , Eli Zaretskii Subject: Re: [PATCH] Support for Xilinx MicroBlaze References: <4ACA9EE8.1040007@eagercon.com> <20091014014655.GL5272@adacore.com> In-Reply-To: <20091014014655.GL5272@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/msg00307.txt.bz2 Joel Brobecker wrote: >> 2009-10-05 Michael Eager >> + /* For sentinel frame, return address is actual PC. For other frames, >> + return address is pc+8. This is a workaround because gcc does not >> + generate correct return address in CIE. */ > > You do what you have to do, but this is *BAD* idea (IMO). Unless you can > detect the case when GCC generates bad return addresses or not in CIE, > you'll end up having a broken debugger as soon as the compiler gets > fixed. Introducing work arounds for compiler deficiencies is often fine, > but I don't think that this should be done at the cost of proper operation. Yes, I agree. But ... I looked at fixing this in gcc a while ago. The translation from rtx to CIE entry doesn't allow expressing PC+8. If I recall, there was another architecture (sparc?) which also has a kludge to overcome this deficiency. Perhaps it is possible to determine whether the CIE contains pc or pc+8 and make the right choice. I'll take a look at this, but I think that this info is lost long before the return address is used. I really don't want to put MicroBlaze-specific checks in the target-independent code which parses the CIE. If it's not possible to tell whether the CIE is generated correctly or not, then the situation is that gdb will be unable to backtrace on a code generated by a fixed compiler, or alternately, if gdb is changed, it will be unable to backtrace on existing object files. Neither is an acceptable choice. >> + struct regcache *regcache = get_current_regcache (); > > This one raised a red flag, as we try to avoid depending on global > variables. But I'm not sure what the kosher way of getting the regcache > would be. I thought there would be method to get the regcache from > a frame, but apparently not. Perhaps the right way is to use > get_thread_arch_regcache (inferior_ptid, gdbarch), but I'm not sure. > I'll ask Ulrich, who knows this area a lot better. I wasn't able to find a better way to get the regcache either. Perhaps it's known farther up the call tree, but it isn't passed to the software single step routine. On the other hand, I'm not sure that this is functionality is necessary in the real world. In an embedded environment, I believe that the target manager (XDM) handles single stepping; on Linux, ptrace does this. I'll check on this and see if I can eliminate the code. -- Michael Eager eager@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077