This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Save the length of inserted breakpoints
> 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.