From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16685 invoked by alias); 30 Aug 2007 10:43:10 -0000 Received: (qmail 16670 invoked by uid 22791); 30 Aug 2007 10:43:08 -0000 X-Spam-Check-By: sourceware.org Received: from s200aog14.obsmtp.com (HELO s200aog14.obsmtp.com) (207.126.144.128) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 30 Aug 2007 10:42:57 +0000 Received: from source ([164.129.1.35]) (using TLSv1) by eu1sys200aob014.postini.com ([207.126.147.11]) with SMTP; Thu, 30 Aug 2007 10:42:46 UTC Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 3776BDB56 for ; Thu, 30 Aug 2007 10:42:46 +0000 (GMT) Received: from mail1.bri.st.com (mail1.bri.st.com [164.129.8.218]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 0C6544BF38 for ; Thu, 30 Aug 2007 10:42:46 +0000 (GMT) Received: from [164.129.14.85] (bri1017.bri.st.com [164.129.14.85]) by mail1.bri.st.com (MOS 3.7.5a-GA) with ESMTP id CJE78296 (AUTH antony); Thu, 30 Aug 2007 11:42:44 +0100 (BST) Message-ID: <46D69F24.8040307@st.com> Date: Thu, 30 Aug 2007 10:43:00 -0000 From: Antony KING User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: gdb@sourceware.org Subject: Re: [RFC] Add commands to dynamically enable/disable shared library support References: <46D41D81.3020003@st.com> <20070828194615.GA2839@caradoc.them.org> In-Reply-To: <20070828194615.GA2839@caradoc.them.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-08/txt/msg00258.txt.bz2 I did not mention in my original post some context about the type of systems we are debugging. They are embedded SoCs containing variants of the SH4 core which are debugged over the JTAG port via a host/target interface box of our own design, called the "ST Micro Connect" or STMC. GDB connects to the STMC using a dedicated target command (which is not GDBServer based but instead uses its own dedicated RPC solution). The target applications are typically running our own RTOS but may also be running without an RTOS. Also, part of the design goal is to minimise the impact of GDB on the target. This means, for example, that we do not perform active thread lifetime monitoring and instead expect the user to refresh the thread list using the "info threads" commands. Of course, when we are debugging applications with ~100 threads we try to ensure that the cost of doing this is minimised by extensive use of caching on the host :-). Another point is that the debug services that GDB uses are not tied to GDB, they are independent (so that they can be used by other tools, such as test S/W). Daniel Jacobowitz wrote: > On Tue, Aug 28, 2007 at 02:05:05PM +0100, Antony KING wrote: >> The intent of this patch is to be able to control the insertion of the >> breakpoint used to monitor when a shared library is loaded (and so >> update GDB's symbolic information). The reason for this is that when >> debugging boot from ROM applications it is only legitimate to insert a >> breakpoint when the application has been re-located from ROM to RAM. At >> present it is only possible to control this by removing the symbolic >> information (so that GDB does not "see" the special symbol in the target >> application). This is not desirable if one wishes to set a breakpoint >> (using a hardware breakpoint) in the loaded application. >> >> I plan to add these commands to the version of GDB we support, unless >> someone suggests a better solution, but I would also like to get a wider >> opinion (other than my own) on the implementation and whether the >> changes a desirable in standard GDB. > > I think that you are fixing a single symptom of a larger problem. True. > It's not specific to shared library support that the breakpoint can't > be set right away. No other software breakpoints can be set at the > start of execution either, and ideally they should be set > automatically after the copy to RAM. Again true but in this case we recommend to our users that they set hardware breakpoints (up to 3 available) at the locations in RAM where the application will eventually be loaded. This is particularly useful when wanting to check that the loader in ROM has correctly done its job (by setting a H/W breakpoint at the start symbol and then comparing the loaded sections against the original executable). > Can we somehow arrange for your target to notify GDB to recheck all > its software breakpoints? That should work if they're just being > overwritten during the copy to RAM. This is a possibility, however it is not obvious given the nature of the software we run how this can be achieved, particularly if part of the application runs from ROM. The mechanism to use to signal GDB that the breakpoints need "refreshing" is not obvious given the nature of the target applications (and the target interface we are using). However your following observation: > If they need to be not inserted at the start of execution, > e.g. because RAM is not yet mapped or the RAM controller initialized, > then we will have to find a more complicated solution. is indeed the case for our target systems (i.e. we usually start debugging from a hardware reset). I do not see an easy way out of this given where I am at today (particularly with the feasibility of providing a hook that GDB can use to detect when it is safe to insert S/W breakpoints). I think for the present I will adopt the solution I have proposed since its meets my immediate objectives (and no one has objected to my use of the enable/disable idiom :-). The solution also has the added benefit of allowing the user some control over this "hidden" breakpoint within GDB which is probably desirable. Cheers, Antony.