From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13478 invoked by alias); 28 Aug 2007 19:46:24 -0000 Received: (qmail 13402 invoked by uid 22791); 28 Aug 2007 19:46:23 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 28 Aug 2007 19:46:18 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 4E28498153; Tue, 28 Aug 2007 19:46:18 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id 32CFB9812E; Tue, 28 Aug 2007 19:46:18 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.67) (envelope-from ) id 1IQ70x-0000mQ-4E; Tue, 28 Aug 2007 15:46:15 -0400 Date: Tue, 28 Aug 2007 19:46:00 -0000 From: Daniel Jacobowitz To: Antony KING Cc: gdb@sourceware.org Subject: Re: [RFC] Add commands to dynamically enable/disable shared library support Message-ID: <20070828194615.GA2839@caradoc.them.org> Mail-Followup-To: Antony KING , gdb@sourceware.org References: <46D41D81.3020003@st.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46D41D81.3020003@st.com> User-Agent: Mutt/1.5.15 (2007-04-09) 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/msg00242.txt.bz2 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. 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. 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. 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. -- Daniel Jacobowitz CodeSourcery