This is the mail archive of the gdb-patches@sourceware.cygnus.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: handle hardware breakpoints in overlays


>>>>> "jtc" == J T Conklin <jtc@redback.com> writes:
jtc> I assumed that GDB had to be notified on every overlay switch, since
jtc> the overlay sections may not be in the address space of the processor
jtc> (it might be loaded from some external device, etc).  If this is not
jtc> the case, I think we can put this patch on the back burner, since hw
jtc> breakpoints will not be inserted and/or removed as overlays are
jtc> swapped.  

jtc> Is there any mechanism for the overlay manager and GDB to cooperate?
jtc> Without it, I can't see how overlay breakpoints can work unless the
jtc> LMA is in writable physical memory.

I've taken a look at symfile.c and have a much better understanding of
GDB's overlay support.  It's a specific and unusual overlay model, one
that cannot support hardware breakpoints without additional support.

If you were using the remote protocol with the breakpoint extension,
the debug agent on the target could cooperate with the overlay manager
--- inserting and removing breakpoints at every overlay switch. But if
we have this level of interaction, you might as well have the debug
agent totally abstract the fact that the target is using overlays.

As I don't have a need for overlays myself, I'm going to back out this
patch in my local tree --- I was hoping to pick off some low hanging
fruit before continuing with changes to avoid inserting and removing
breakpoints.  

        --jtc

-- 
J.T. Conklin
RedBack Networks

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]