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

[Antony KING <antony dot king at st dot com>]

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.