Re: Save the length of inserted breakpoints

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 4 Mar 2006 10:05:14 -0500
> From: Daniel Jacobowitz <drow@false.org>
> 
> On Sat, Mar 04, 2006 at 04:54:04PM +0200, Eli Zaretskii wrote:
> > > Date: Sat, 4 Mar 2006 09:43:30 -0500
> > > From: Daniel Jacobowitz <drow@false.org>
> > > 
> > > > > There's a division in GDB between the target, which is a method of
> > > > > communication et cetera ("how"), and the architecture, which describes
> > > > > "what" is being debugged.
> > > > 
> > > > Btw, is this division described anywhere?
> > > 
> > > Yes, extensively, in gdbint.
> > 
> > I looked there before asking, so please tell what is the section name
> > that describes this.  Sorry for being blind.
> 
> They have their own chapters: Target Architecture Definition and Target
> Vector Definition.  Perhaps the titles could be clarified.
> 
> GDB's target architecture defines what sort of machine-language
> programs GDB can work with, and how it works with them.
> 
> versus
> 
> The target vector defines the interface between GDB's abstract handling
> of target systems, and the nitty-gritty code that actually exercises
> control over a process or a serial port.

I saw these.  The definition of the target vector is quite specific,
while that of the architecture, IMNSHO, doesn't explain anything.  In
particular, the usual meaning of the word ``architecture'' does not go
well with ``the sort of machine-language programs''.  The fact that
both terms use the word ``target'' (target architecture vs target
vector) doesn't help, either.

Perhaps a more elaborate description which lists at least the more
important parts of the architecture and, respectively, the target
vector, will make the docs better.  Would someone ``in the know'' care
to write it?

> > > The CPSR support is turning out to be a remarkable pain for such a
> > > simple change.
> > 
> > That's why I thought we should discuss the design aspects here.
> 
> Do you have any suggestions for the design?

Well, you say that this issue is between the target and the
architecture, so keeping the info in those layers seems like a good
start.  Does this make sense?

> Heh... another way I could make the interface more symmetric would be
> to bump up the size of the shadow contents vector, and have targets
> which care about the size store the length in there when inserting
> the breakpoint.

Sounds a bit unclean to me.