[RFC] Add commands to dynamically enable/disable shared library support

[RFC] Add commands to dynamically enable/disable shared library support

[Antony KING]

[-- Attachment #1: Type: text/plain, Size: 1366 bytes --]

Hi,

Attached is a patch I have constructed against GDB 6.6 which adds the
following commands to GDB:

* disable sharedlibrary

  This command removes the shared library breakpoints and implicitly
calls the "nosharedlibrary" command. The solib_create_inferior_hook()
API is also disabled (until re-enabled by "enable sharedlibrary").

* enable sharedlibrary

  This command explicitly calls the solib_create_inferior_hook() API and
re-enables the auto loading of shared libraries.

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.

Cheers,

Antony.

[-- Attachment #2: patch-INSbl26139.txt --]
[-- Type: text/plain, Size: 1853 bytes --]

--- gdb/solib.c@@/main/INSIGHT-6.6-ST-1.0-int/LATEST	2007-08-28 11:30:33.257546000 +0100
+++ gdb/solib.c	2007-08-28 11:26:54.360656000 +0100
@@ -82,6 +82,8 @@
 
 static int solib_cleanup_queued = 0;	/* make_run_cleanup called */
 
+static int solib_enabled = 1;		/* Shared libraries enabled ? */
+
 /* Local function prototypes */
 
 static void do_clear_solib (void *);
@@ -869,7 +871,8 @@
 solib_create_inferior_hook (void)
 {
   struct target_so_ops *ops = solib_ops (current_gdbarch);
-  ops->solib_create_inferior_hook();
+  if (solib_enabled)
+    ops->solib_create_inferior_hook();
 }
 
 /* GLOBAL FUNCTION
@@ -951,6 +954,39 @@
 		    value);
 }
 
+/* LOCAL FUNCTION
+
+   disable_shared_libraries -- handle command to disable shared library
+   support.
+
+   DESCRIPTION
+
+   Implements the command "disable sharedlibrary".  */
+
+static void
+disable_shared_libraries (char *ignored, int from_tty)
+{
+  solib_enabled = 0;
+  remove_solib_event_breakpoints ();
+  no_shared_libraries (NULL, from_tty);
+}
+
+/* LOCAL FUNCTION
+
+   enable_shared_libraries -- handle command to enable shared library
+   support.
+
+   DESCRIPTION
+
+   Implements the command "enable sharedlibrary".  */
+
+static void
+enable_shared_libraries (char *ignored, int from_tty)
+{
+  solib_enabled = 1;
+  solib_create_inferior_hook ();
+  solib_add (NULL, from_tty, NULL, auto_solib_add);
+}
 
 extern initialize_file_ftype _initialize_solib; /* -Wmissing-prototypes */
 
@@ -1001,4 +1037,12 @@
 				     reload_shared_libraries,
 				     show_solib_search_path,
 				     &setlist, &showlist);
+
+  add_cmd ("sharedlibrary", class_support, disable_shared_libraries, _("\
+Disable shared library support."),
+	   &disablelist);
+
+  add_cmd ("sharedlibrary", class_support, enable_shared_libraries, _("\
+Enable shared library support."),
+	   &enablelist);
 }

Re: [RFC] Add commands to dynamically enable/disable shared library support

[Eli Zaretskii]

> Date: Tue, 28 Aug 2007 14:05:05 +0100
> From: Antony KING <antony.king@st.com>
> 
> Attached is a patch I have constructed against GDB 6.6 which adds the
> following commands to GDB:

Thanks!

However, patches should be sent to gdb-patches@, not here.

I have no opinion on the patch, but if it is accepted, please add a
patch for the user manual to describe these new commands.  We want all
the commands to be documented in the manual.

Thanks again for working on this.

Re: [RFC] Add commands to dynamically enable/disable shared library support

[Antony KING]

Thanks for the advice.

(I pondered on whether to use the patch mailing list or this one but I
decided against since this was really a "shot in the dark" about an idea
I had and I thought I would try it here first for some feedback before
trying to submit a complete patch. :-)

Cheers,

Antony.

Eli Zaretskii wrote:
>> Date: Tue, 28 Aug 2007 14:05:05 +0100
>> From: Antony KING <antony.king@st.com>
>>
>> Attached is a patch I have constructed against GDB 6.6 which adds the
>> following commands to GDB:
> 
> Thanks!
> 
> However, patches should be sent to gdb-patches@, not here.
> 
> I have no opinion on the patch, but if it is accepted, please add a
> patch for the user manual to describe these new commands.  We want all
> the commands to be documented in the manual.
> 
> Thanks again for working on this.
> 

Re: [RFC] Add commands to dynamically enable/disable shared library support

[Daniel Jacobowitz]

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

Re: [RFC] Add commands to dynamically enable/disable shared library support

[Antony KING]

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.

Re: [RFC] Add commands to dynamically enable/disable shared library support

[Daniel Jacobowitz]

On Thu, Aug 30, 2007 at 11:42:44AM +0100, Antony KING wrote:
> I did not mention in my original post some context about the type of
> systems we are debugging.

Yes, thanks for the background.  This matches what I assumed you were
doing.

> > 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:

Of course it's not obvious :-)  The question is whether it is _better_.
If GDB can detect (A) whether the application is running from ROM or
RAM right now, and (B) whether it is going to copy itself to RAM,
and (C) somewhere useful to set a breakpoint that will be triggered
when that happens, then it can handle everything transparently.  This
is much nicer for the user; e.g., it allows an IDE that doesn't know
anything about your target to seamlessly debug across the copy.

And it's useful for more targets than just yours, too.

I can easily answer (A).  The remote protocol nowadays includes memory
map support; you can tell GDB where ROM is and where RAM is.  So we
know whether the current PC is in ROM.  Though if your target's
applications copy only parts of their code to RAM and run less
frequently accessed bits from ROM, this won't suffice.

Do ELF files for your target have the LMA pointing at ROM and the VMA
pointing at RAM?

> 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.

For what it's worth, I don't really think this is desirable.  But then
I haven't used systems where you have to use a hardware breakpoint to
implement it, so maybe it is in your case.

-- 
Daniel Jacobowitz
CodeSourcery