Re: Save the length of inserted breakpoints

[Steven Johnson <sjohnson@sakuraindustries.com>]

Eli Zaretskii wrote:

>>Date: Fri, 3 Mar 2006 12:54:07 -0500
>>From: Daniel Jacobowitz <drow@false.org>
>>Cc: gdb-patches@sourceware.org
>>
>>If every target cached the size of inserted breakpoints and made sure
>>to remove them at the same size, that would work too, but right now
>>most targets don't need to remember anything about the breakpoints
>>they've inserted; the common layer of GDB handles it.
>>    
>>
>
>That sounds like an unfortunate design.  If we are to make significant
>changes to handle the complications that led you to this patch,
>perhaps we should consider changing the design instead.
>
>
>  
>
I wouldn't have thought the design unfortunate.  One original aim of the
target stubs (as i understand it) was to be able to keep them simple and
minimal.  That would include minimizing their memory requirements. 
Requiring a stub to store state about current breakpoints inserted would
be a potentially big memory requirement, because how many breakpoints is
the user going to insert? 1, 2, 50, 100's?  Or do the stubs just limit
it, and say, i'm a simple stub, i can only have 5 breakpoints, try
adding 6 and I'll fail? 

I think the approach to use the "effectively infinite" resources of the
host PC to cache the breakpoint information is the correct approach,
given the alternative. (For stubs that don't implement the 'z' packets).

However if a stub implement the 'z' packets, it needs to store state of
the breakpoints, so why does it need to know the size of the breakpoint
on remove?  It should have already cached the data at the location, it
should already have stored how much data it cached, so surely just
"Remove the breakpoint a x' is enough for the stub to complete its job. 
This doesn't fix the basic problem for simple stubs that only have
read/write memory control where GDB caches all of the info.

Steven