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

[Daniel Jacobowitz <drow@false.org>]

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