Re: none

[Jim Blandy <jimb@cygnus.com>]

> > For register views, yes, we can do anything we please.  However, when
> > the compiler places a register in an MMX register value, we still get
> > an old-fashioned symbol with a LOC_REGISTER.  Register views don't
> > come into it.  As long as we only have a LOC_REGISTER, we don't have
> > enough information to do the job right.
> 
> I probably don't understand how this works.  How is the LOC_REGISTER
> thing different from the case where the user specifies a certain
> register (e.g., when the user wants to change its value)?  At any
> given point in a debugging session, GDB knows what is the current TOS,
> and therefore can map any MMX register to the corresponding ST(i),
> right?

If a symbol's address class (`aclass') is LOC_REGISTER and its value
is N, then GDB assumes the variable's value occupies register N.  It
uses REGISTER_BYTE(N), REGISTER_RAW_SIZE(N), etc. to access that
symbol's value.

We can't assign distinct register numbers to %st(0) and %mm0, for
reasons discussed previously: GDB can't cope with two distinct
register numbers referring to the same bits in the register file.

We can't use the same register numbers for %st(0) and %mm0, since
they're only the same bits when TOS is zero.

So there is no possible register numbering which allows us to refer to
both %st(0) and %mm0.  Therefore, %st(0) and %mm0 cannot both be
`registers', as far as GDB is concerned.
From shebs@cygnus.com Tue Nov 30 13:16:00 1999
From: Stan Shebs <shebs@cygnus.com>
To: cgf@cygnus.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: Extra Thread Info
Date: Tue, 30 Nov 1999 13:16:00 -0000
Message-id: <199911302116.NAA00394@andros.cygnus.com>
References: <81i3de$kj6$1@cronkite.cygnus.com>
X-SW-Source: 1999-q4/msg00367.html
Content-length: 1070

   From: cgf@cygnus.com (Chris Faylor)
   Date: 25 Nov 1999 01:29:18 GMT

   When I added thread support for Windows I wished for an additional field
   or two in gdb's thread structure which would have allowed me to store
   extra OS specific state about a thread.  It would only have to be an
   opaque void * pointer of use only to the target.  This would have saved
   a fair amount of head-standing in win32-nat.c.

   But, I don't think that this is exactly what you're talking about.
   Having some kind of extensible way to query and report thread
   information would be nice.  At the very simplest an additional target
   vector could be supplied which returned extra information to tack onto
   info thread output.

Actually, this is a perfect example, and yes, the implementation would
use an additional target vector entry.

This isn't the first time the desire has come up for additional info
about threads, but for natives the solution is easy - just add a
system-specific command to foo-nat.c.  This still loses for
cross-debugging though.

								Stan
From shebs@cygnus.com Tue Nov 30 13:55:00 1999
From: Stan Shebs <shebs@cygnus.com>
To: jlarmour@cygnus.co.uk
Cc: msalter@cygnus.com, jtc@redback.com, gdb@sourceware.cygnus.com
Subject: Re: Extra Thread Info
Date: Tue, 30 Nov 1999 13:55:00 -0000
Message-id: <199911302155.NAA11699@andros.cygnus.com>
References: <199911250727.HAA31443@peshwari.cygnus.co.uk>
X-SW-Source: 1999-q4/msg00368.html
Content-length: 3113

   Date: Thu, 25 Nov 1999 07:27:38 GMT
   From: jlarmour@cygnus.co.uk (Jonathan Larmour)

   >Perhaps the eCos developers' judgment is flawed, but they certainly
   >preferred adding a packet over the alternative of encoding eCos
   >internals into GDB, whether it was as scripts or C code.  But this
   >decision was made a couple years ago; I'll bring it up with them
   >again, perhaps they've changed their minds about this point.

   Nope :-). At least not unless the scripts can adapt when the kernel thread
   structure can change from program to program. Hard-coded C is right out.

   It's feasible to enhance GDB scripting to do this right, but it certainly
   isn't possible now. And then there are the other problems like it not
   being usable from anything other than the CLUI. 

Thanks for the info, I didn't even think about the effect of eCos
configurability.

   But it's the performance that's the real killer. Remote debugging over
   wet string is slow enough, but add in the latency of script interpretation,
   and having to synchronously query each item of thread state with separate
   memory reads, and you have an unusable system. eCos is only requesting
   the ID, name, and state in addition to the normal info, and the info is
   returned in one packet per thread. But it takes around 1 second per thread
   with a 38400bps link. It's not nice, but it we really must not do anything
   to make it slower, which scripting would do a lot.

I think this is all optimizable - nobody has spent any time on
improvements since the original implementation.  We're certainly not
picking up 4K of useful info about each thread...

   NB Other OS's may well find it very difficult to export internal structures
   without actually having large sections of the OS itself compiled with
   debug info, which may well be unacceptable. eCos doesn't mind as we're 
   open source, but I don't think we should discriminate. The type information
   encoded in the debug info is much more interesting than the actual symbols
   of course.

While it's a problem, it's not really very serious, because you can
pick up the info just by including some sort of <thread_struct.h> in
your app somewhere.  Often you have to do that anyway just to use
threads in the first place.  Still, enough users will forget this, or
experience the linker doing symbol GC, or whatever, so it will make
scripts seem unreliable.

   I think what is required is to draw up a list of all the thread concepts
   we already know that users would want to know about: thread ID, name,
   priority, state, stack frame at least. A target stub may support any or
   all of these. 

The name makes sense as a general concept - Tom Tromey points out that
it's useful for Java too - and stack frame is implicit in the thread's
register set.  Priority and state are rather variable in nature, which
I would prefer to have them be glommed into a single string.  As a
corollary, I'm not too keen on building in an elaborate bitmap
mechanism, but there are other ways to reduce bandwidth, I'll think
about the issue a bit more.

								Stan
From shebs@cygnus.com Tue Nov 30 14:46:00 1999
From: Stan Shebs <shebs@cygnus.com>
To: msalter@cygnus.com
Cc: jtc@redback.com, gdb@sourceware.cygnus.com
Subject: Re: Extra Thread Info
Date: Tue, 30 Nov 1999 14:46:00 -0000
Message-id: <199911302246.OAA28180@andros.cygnus.com>
References: <199911281854.NAA20537@msalter2.cygnus.com>
X-SW-Source: 1999-q4/msg00369.html
Content-length: 3949

   Date: Sun, 28 Nov 1999 13:54:42 -0500
   From: Mark Salter <msalter@cygnus.com>

   > Perhaps the eCos developers' judgment is flawed, but they certainly
   > preferred adding a packet over the alternative of encoding eCos
   > internals into GDB, whether it was as scripts or C code.

   I wouldn't say their judgement is flawed. I would agree with their
   decision if debugging using the remote protocol were the only 
   debugging environment to be considered. But you erect a strawman, here.
   I never suggested encoding eCos (or any other) OS internals in gdb.

If the info is encoded in a script that always ships with GDB, then
from my point of view, it's part of GDB.  Sometimes it's unavoidable;
GDB sources include all kinds of gory detail about AIX, HP-UX, etc,
some of which was acquired by reverse engineering and experimentation.
But we only want to do that if absolutely necessary; if there is a
defined API or protocol, we would much rather use that instead.

     But this
   > decision was made a couple years ago; I'll bring it up with them
   > again, perhaps they've changed their minds about this point.

   I wasn't aware that the eCos group was the sole arbiter of this issue.

Of course not!  I'm the sole arbiter. :-) But as an open-source RTOS
that uses GDB as its primary debugger, eCos is an important client,
and it's worth considering how best to accommodate it, and how that
used to improve OS support in general.

   > It's certainly always possible to write something that works for a
   > particular situation.  My concern is that we're supposed to be
   > supplying something that works consistently for users across both GDB
   > and OS revs.

   GDB shouldn't have to worry about OS revs. I'm assuming that the script
   to extract thread info from a target is provided and maintained by the
   OS vendor, not the gdb maintainers.

So each vendor provides a script with a different name, and it has to
also get a different name whenever the OS changes, and the user has to
know which script to use.  Seems less desirable than an "info threads"
or "info extra" that has the same usage for everybody.

   >    A gui can do what a gdb script does and use memory read operations
   >    to get the info it needs.

   > Which means that each GUI now has to have its own version of the same
   > thread-groveling script?  Sounds like an MxN problem.

   No, the OS vendor-supplied thread-groveling scripts provide an interface
   to thread info that can be used from a CLUI or from a GUI.

How is the GUI to collect the script's output though?  By parsing it?
If so, then you have to specify the output format of scripts written
by random third parties, not to mention writing the parser.  This is
getting to be an awful lot of work just to avoid adding ~20 lines to
GDB.  Certainly if somebody wants to provide all-singing all-dancing
OS support, they'll have to do that anyway, but that's OK; I just want
GDB to provide a very basic level of thread info support that lets
people use it without a lot of work, and that does not preclude adding
something more elaborate later on.

   This solution by definition, only works if you are using the remote
   protocol. It does not address gdb's debugging interface to simulators.
   This is a huge deficiency in my opinion.

Implementationwise I was going to add a target vector entry per the
usual process; the concept of extra thread info is not specific to the
remote protocol.  Then we can do extra thread info for Win32 if
desired, etc.

I'm not too concerned about simulators, because I haven't personally
seen or heard of any simulators that had an OS implicitly buried in
them, such that remote-sim.c had to implement thread methods itself -
certainly there are none such in GNU right now.  The whole idea
involves so many variables that I'd want to hear about the
architecture of a real example, before trying to design GDB to
accommodate it.

								Stan
From jtc@redback.com Tue Nov 30 15:11:00 1999
From: jtc@redback.com (J.T. Conklin)
To: Stan Shebs <shebs@cygnus.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Extra Thread Info
Date: Tue, 30 Nov 1999 15:11:00 -0000
Message-id: <5mr9h74lsx.fsf@jtc.redbacknetworks.com>
References: <199911232211.OAA25604@andros.cygnus.com>
X-SW-Source: 1999-q4/msg00370.html
Content-length: 3390

>>>>> "Stan" == Stan Shebs <shebs@cygnus.com> writes:
jtc> Besides your three suggestions, I prefer a fourth: provide
jtc> target specific user defined functions which traverse the
jtc> thread table and presents the information in a useful format.
jtc> This doesn't bind any knowledge about any particular thread
jtc> implementation into GDB; is easily modifyable by the end user
jtc> (rather than a GDB hacker) to add, remove, or change the
jtc> presentation of thread information; and should not require
jtc> any changes to the target.

Stan> I didn't mention this option because it has a couple fatal
Stan> flaws.

I didn't think of these as flaws, as I was thinking along the lines
that any info gathering mechanism had to be built on top the existing
target primitives, otherwise it would be limited to a small subset of
targets.  That is what I would consider a fatal flaw.

And if you compare the difficulty of implementing data structure
groveling code in GDB's C code vs. doing the same in a GDB script, 
I think the choice is clear.  

Stan> First, it doesn't work if the OS doesn't have a thread
Stan> table.  What if the OS calculates it on the fly, or expects the
Stan> programmer to choose the location of the table or whatever
Stan> structure it is?

If the OS computes a thread table on the fly, we should be able to do
the same in a GDB script.  It may not be pleasant do to so.

Stan> Second, it requires a set of symbols.  In your VxWorks example,
Stan> you manage to have WIND_TCB and activeQHead.pFirstNode available
Stan> somehow.  I can't justify requiring an OS to expose its private
Stan> data structures, nor requiring users to link the definitions of
Stan> the data structures into their applications, whether or not the
Stan> application uses those structures directly.  (There is also a
Stan> potential usability problem with getting the compiler to include
Stan> unused symbols in an executable.)

That's just one example of one way to do it.

The point is a target is going to have to expose *some* method of
obtaining the thread list.  It may be the symbols that make up the
list, it may be a function that when called fills in a buffer, etc.
If the vendor makes the thread list available at all, there has to
be some mechanism of obtaining it.  If they don't, a stub will not
be able to obtain the same information for a remote protocol 
extension either.

Stan> Third, there's no internal pathway for GUI clients to get the
Stan> information and do their own thing with it.  In other words,
Stan> scripts cannot presently be used to implement any part of a
Stan> libgdb API.

This probably needs to be addressed.  There are many current commands
--- primarily those that present target information like info reg ---
that should be scripts.  There are others where it would be useful to
call out to script `hooks'.

Stan> An additional non-fatal objection is that GDB's scripting
Stan> machinery is too weak to depend on as an integral part of the
Stan> debugger.  

As a language, it's weak.  As an implementation, it seems pretty
solid.

Stan> It's good enough for people to develop scripts for use inhouse,
Stan> but imagine trying to manage and distribute dozens of
Stan> configuration-specific script files; it would be a disaster.

No worse than embedding target specific knowlege into GDB's C files.

        --jtc

-- 
J.T. Conklin
RedBack Networks
From jtc@redback.com Tue Nov 30 15:28:00 1999
From: jtc@redback.com (J.T. Conklin)
To: jlarmour@cygnus.co.uk (Jonathan Larmour)
Cc: shebs@cygnus.com, msalter@cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: Extra Thread Info
Date: Tue, 30 Nov 1999 15:28:00 -0000
Message-id: <5mn1rv4l1e.fsf@jtc.redbacknetworks.com>
References: <199911250727.HAA31443@peshwari.cygnus.co.uk>
X-SW-Source: 1999-q4/msg00371.html
Content-length: 1051

>>>>> "Jonathan" == Jonathan Larmour <jlarmour@cygnus.co.uk> writes:
Jonathan> I think what is required is to draw up a list of all the
Jonathan> thread concepts we already know that users would want to
Jonathan> know about: thread ID, name, priority, state, stack frame at
Jonathan> least. A target stub may support any or all of these.

The problem is that this is an open ended set of variables, and they
are represented with different types in different OSs.  For example,
to debug problems at different times I've had to look at thread ID,
name, priority, inherited priority, state, stack bounds (stack top &
bottom, and current stack pointer), number of ticks since task was
last scheduled, number of interrupts received while in this task's
context, number of times task has be placed on run queue, number of
times task has been preemted, number of times task has yielded
unconditionally, etc., etc., etc.  And that's just my list.  Combine
that with everyone elses, and it gets out of hand...

        --jtc

-- 
J.T. Conklin
RedBack Networks
From jtc@redback.com Tue Nov 30 15:53:00 1999
From: jtc@redback.com (J.T. Conklin)
To: Stan Shebs <shebs@cygnus.com>
Cc: msalter@cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: Extra Thread Info
Date: Tue, 30 Nov 1999 15:53:00 -0000
Message-id: <5miu2j4jul.fsf@jtc.redbacknetworks.com>
References: <199911302246.OAA28180@andros.cygnus.com>
X-SW-Source: 1999-q4/msg00372.html
Content-length: 1285

>>>>> "Stan" == Stan Shebs <shebs@cygnus.com> writes:
Stan> I'm not too concerned about simulators, because I haven't
Stan> personally seen or heard of any simulators that had an OS
Stan> implicitly buried in them, such that remote-sim.c had to
Stan> implement thread methods itself - certainly there are none such
Stan> in GNU right now.  The whole idea involves so many variables
Stan> that I'd want to hear about the architecture of a real example,
Stan> before trying to design GDB to accommodate it.

That's just the point.  

A simulator (or ICE) environment is a blank slate --- just like a
random piece of target hardware.  It might run eCos, RTEMS, vxWorks,
IOS, etc.  It does not (and IMO it should not) have any knowlege of
the OS running on it.  

Ideally the same generic embedded GDB should be able to debug all of
these OSs.  But instead of going through an intermediary debug agent,
GDB (or an ICE under GDB's control) can examine and manipulate the
targets memory and registers directly.  Thus it seems wrong to put OS
specific knowledge in the simulator's target vector.  It should be at
a higher level so that it can use the primitives provided by every 
target.

The same issues are found in examining crash dumps.

        --jtc

-- 
J.T. Conklin
RedBack Networks
From shebs@cygnus.com Tue Nov 30 15:57:00 1999
From: Stan Shebs <shebs@cygnus.com>
To: jtc@redback.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: Extra Thread Info
Date: Tue, 30 Nov 1999 15:57:00 -0000
Message-id: <199911302352.PAA03068@andros.cygnus.com>
References: <5mr9h74lsx.fsf@jtc.redbacknetworks.com>
X-SW-Source: 1999-q4/msg00373.html
Content-length: 2691

   From: jtc@redback.com (J.T. Conklin)
   Date: 30 Nov 1999 15:11:26 -0800

   I didn't think of these as flaws, as I was thinking along the lines
   that any info gathering mechanism had to be built on top the existing
   target primitives, otherwise it would be limited to a small subset of
   targets.  That is what I would consider a fatal flaw.

   And if you compare the difficulty of implementing data structure
   groveling code in GDB's C code vs. doing the same in a GDB script, 
   I think the choice is clear.  

I think there's some confusion here.  The extra thread info I'm
referring to is already being collected by a special type of packet in
the standard protocol.  As far as I know only eCos uses that packet,
but since it's been in the sources for a year, it's possible that some
other OS is using it too.  The display of the info is also already
written, but it's only in the version of the sources that you can
download along with eCos.  It does nothing more than printf three
additional strings that were received in the special thread packet -
and one of those strings is always empty these days.

So neither the regular nor the eCos GDB do any groveling of data
structures, nor am I proposing such an addition.  What I'm proposing
is to create an abstract notion of additional thread info, and to
regularize its handling, so that if it's appropriate for the target OS
to do the dirty work itself, it can, and then GDB simply passes the
data through for the user to see.

   The point is a target is going to have to expose *some* method of
   obtaining the thread list.  It may be the symbols that make up the
   list, it may be a function that when called fills in a buffer, etc.
   If the vendor makes the thread list available at all, there has to
   be some mechanism of obtaining it.  If they don't, a stub will not
   be able to obtain the same information for a remote protocol 
   extension either.

If the stub is part of the OS, then it has the ability to collect
thread info.  In fact, a thread-supporting stub already has to be
able to get basic thread info, so it already has a way to collect
threads and report them.

This is just another example of putting functionality in the stub for
the sake of consistency and performance.  It's not really any
different from having stubs manage breakpoints, watchpoints, searches,
or any of the other stub-complicating performance-enhancing changes
that have been proposed in the past.  I think this one "feels"
different in that it addresses higher levels of functionality, but as
I've mentioned in a previous message, users want more functionality
and more OS support in the debugger, not less.

								Stan
From shebs@cygnus.com Tue Nov 30 15:58:00 1999
From: Stan Shebs <shebs@cygnus.com>
To: jtc@redback.com
Cc: jlarmour@cygnus.co.uk, msalter@cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: Extra Thread Info
Date: Tue, 30 Nov 1999 15:58:00 -0000
Message-id: <199911302358.PAA03505@andros.cygnus.com>
References: <5mn1rv4l1e.fsf@jtc.redbacknetworks.com>
X-SW-Source: 1999-q4/msg00374.html
Content-length: 1427

   From: jtc@redback.com (J.T. Conklin)
   Date: 30 Nov 1999 15:27:57 -0800

   >>>>> "Jonathan" == Jonathan Larmour <jlarmour@cygnus.co.uk> writes:
   Jonathan> I think what is required is to draw up a list of all the
   Jonathan> thread concepts we already know that users would want to
   Jonathan> know about: thread ID, name, priority, state, stack frame at
   Jonathan> least. A target stub may support any or all of these.

   The problem is that this is an open ended set of variables, and they
   are represented with different types in different OSs.  For example,
   to debug problems at different times I've had to look at thread ID,
   name, priority, inherited priority, state, stack bounds (stack top &
   bottom, and current stack pointer), number of ticks since task was
   last scheduled, number of interrupts received while in this task's
   context, number of times task has be placed on run queue, number of
   times task has been preemted, number of times task has yielded
   unconditionally, etc., etc., etc.  And that's just my list.  Combine
   that with everyone elses, and it gets out of hand...

A couple of the values you mention remind me - how is direct thread
access supposed to work for a memory-protected OS, for instance for
Posix threads on a Unix-type system, say embedded Linux?  It would be
pretty heinous to try to make scripts call ptrace (or ttrace on HP-UX)
directly...

								Stan
From jtc@redback.com Tue Nov 30 16:25:00 1999
From: jtc@redback.com (J.T. Conklin)
To: gdb@sourceware.cygnus.com
Subject: memory verify
Date: Tue, 30 Nov 1999 16:25:00 -0000
Message-id: <5memd74iem.fsf@jtc.redbacknetworks.com>
X-SW-Source: 1999-q4/msg00375.html
Content-length: 1542

I was thinking about the compare-sections command found in remote.c
and also adding a 'verify' attribute to my memory region code.  

We need a target primitive for doing memory verifies.  There are three
mechanisms that I can think of that can be used for this.  Download a
chunk of memory and an address and have the target determine whether
they are the same; upload a chunk of memory at an address and have GDB
perform the comparison; and perform a CRC or strong hash function on
both the host and the target and compare the results.

The second can be trivially implemented using the target vector's
memory read function.  However verify performance can be improved 
if the target supplies either a compare memory or checksum command.

I propose the following new verify primitive:

    /* Verify that memory at GDB address MYADDR and target address
       MEMADDR are identical.  This can be done by downloading the
       memory region to the target and having it do the comparison;
       uploading the memory region to GDB and having it do the
       comparision; using a checksum, cyclic redundency check, or 
       cryptographic hash function; etc. 

       Return value, N, is one of the following:

       0 - memory region is not identical.

       1 - memory region is identical. */

    int (*to_verify_memory) (CORE_ADDR memaddr, char *myaddr, int len);


If the target cannot handle a memory region of that SIZE, the function
is responsible for breaking it up into chunks.

        --jtc

-- 
J.T. Conklin
RedBack Networks
From shebs@cygnus.com Tue Nov 30 16:43:00 1999
From: Stan Shebs <shebs@cygnus.com>
To: jtc@redback.com
Cc: msalter@cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: Extra Thread Info
Date: Tue, 30 Nov 1999 16:43:00 -0000
Message-id: <199912010043.QAA15210@andros.cygnus.com>
References: <5miu2j4jul.fsf@jtc.redbacknetworks.com>
X-SW-Source: 1999-q4/msg00376.html
Content-length: 3034

   From: jtc@redback.com (J.T. Conklin)
   Date: 30 Nov 1999 15:53:38 -0800

   >>>>> "Stan" == Stan Shebs <shebs@cygnus.com> writes:
   Stan> I'm not too concerned about simulators, because I haven't
   Stan> personally seen or heard of any simulators that had an OS
   Stan> implicitly buried in them, such that remote-sim.c had to
   Stan> implement thread methods itself - certainly there are none such
   Stan> in GNU right now.  The whole idea involves so many variables
   Stan> that I'd want to hear about the architecture of a real example,
   Stan> before trying to design GDB to accommodate it.

   That's just the point.  

   A simulator (or ICE) environment is a blank slate --- just like a
   random piece of target hardware.  It might run eCos, RTEMS, vxWorks,
   IOS, etc.  It does not (and IMO it should not) have any knowlege of
   the OS running on it.  

This is misleading, because GDB's basic thread control has to be part
of the target vector today.  Because remote-sim.c is missing
implementations of the key methods, GDB cannot do even basic thread
debugging with any of the builtin simulators, even if the simulator is
executing a thread-supporting OS.  That's not to say that it couldn't
be done, but it would involve some decisions and some hacking.  For
instance, suppose you want to model a multiprocessor with a builtin
sim, and have each processor appear to be a thread.  That could be
made to work.  Now suppose you want to run a thread-supporting OS on
your simulated multi-processor - should remote-sim.c report the
processor "threads" or the OS threads.  You may even want to switch
back and forth!  Whatever your choice, GDB must know all about how to
start and stop each kind of thread, and how to display the list of
threads.

So as long as GDB supports basic thread debugging, it will have
to have some knowledge of the OS implementing the threads.

In any case, GDB does have all kinds of OS-specific knowledge for
native OSes - what makes them so different?  Indeed, native GDB has to
have a whole separate set of code to access basic thread info in
corefiles, because it can't make ptrace/ttrace calls then.

   Ideally the same generic embedded GDB should be able to debug all of
   these OSs.  But instead of going through an intermediary debug agent,
   GDB (or an ICE under GDB's control) can examine and manipulate the
   targets memory and registers directly.  Thus it seems wrong to put OS
   specific knowledge in the simulator's target vector.  It should be at
   a higher level so that it can use the primitives provided by every 
   target.

Nobody is stopping you from using only primitives for your work.  But
you're saying that everybody should be made to use primitives, and
that they must design their OS to accommodate that usage, whether or
not it's reasonable for them.  We're supposed to be adapting the
debugger to meet the needs of the users, not forcing the users to
conform to our preconceptions about how the debugger should be
structured internally.

								Stan
From ac131313@cygnus.com Tue Nov 30 17:26:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: jtc@redback.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: memory verify
Date: Tue, 30 Nov 1999 17:26:00 -0000
Message-id: <384478F8.B079BDC2@cygnus.com>
References: <5memd74iem.fsf@jtc.redbacknetworks.com>
X-SW-Source: 1999-q4/msg00377.html
Content-length: 2527

"J.T. Conklin" wrote:

> We need a target primitive for doing memory verifies.  There are three
> mechanisms that I can think of that can be used for this.  Download a
> chunk of memory and an address and have the target determine whether
> they are the same; upload a chunk of memory at an address and have GDB
> perform the comparison; and perform a CRC or strong hash function on
> both the host and the target and compare the results.
> 
> The second can be trivially implemented using the target vector's
> memory read function.  However verify performance can be improved
> if the target supplies either a compare memory or checksum command.
> 
> I propose the following new verify primitive:
> 
>     /* Verify that memory at GDB address MYADDR and target address
>        MEMADDR are identical.  This can be done by downloading the
>        memory region to the target and having it do the comparison;
>        uploading the memory region to GDB and having it do the
>        comparision; using a checksum, cyclic redundency check, or
>        cryptographic hash function; etc.
> 
>        Return value, N, is one of the following:
> 
>        0 - memory region is not identical.
> 
>        1 - memory region is identical. */
> 
>     int (*to_verify_memory) (CORE_ADDR memaddr, char *myaddr, int len);
> 
> If the target cannot handle a memory region of that SIZE, the function
> is responsible for breaking it up into chunks.

Yes it's needed.  It will allow me to eliminate a few more FIXME's :-). 
Several thoughts:

I suspect that something like ``compare'' would convey a clearer meaning
than ``verify''.  Verify makes me think of a 20 line assembler program
squeezed into a rom that verifies that memory is working :-)

Rather than to_XXX_memory() handling broken transfers, I'd prefer it if
the primitive returned the number of bytes matched by a single chunk. 
That keeps the primative simple.  It would also be consistent with
->to_xfer_memory().  A value <=0 would indicate no match (exactly what
zero means, given the spec for to_xfer_memory(), is ``left as an
exercise for the reader'' ;-)
A wrapper function could then provide the semantics you're looking for.

What should the target do if it isn't able to provide a more efficient
compare mechanism?  My guess is leave the entry empty so that the higher
level code is able to differentiate between an efficient target memory
compare and a brutal memory read/compare.  That would suggest
target_XXX_memory_p() and target_XXX_memory().

	enjoy,
		Andrew
From jtc@redback.com Tue Nov 30 17:49:00 1999
From: jtc@redback.com (J.T. Conklin)
To: Andrew Cagney <ac131313@cygnus.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: memory verify
Date: Tue, 30 Nov 1999 17:49:00 -0000
Message-id: <5maenv4ehr.fsf@jtc.redbacknetworks.com>
References: <5memd74iem.fsf@jtc.redbacknetworks.com> <384478F8.B079BDC2@cygnus.com>
X-SW-Source: 1999-q4/msg00378.html
Content-length: 1825

>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
Andrew> I suspect that something like ``compare'' would convey a
Andrew> clearer meaning than ``verify''.  Verify makes me think of a
Andrew> 20 line assembler program squeezed into a rom that verifies
Andrew> that memory is working :-)

Andrew> Rather than to_XXX_memory() handling broken transfers, I'd
Andrew> prefer it if the primitive returned the number of bytes
Andrew> matched by a single chunk.  That keeps the primative simple.
Andrew> It would also be consistent with to_xfer_memory().  A value
Andrew> <=0 would indicate no match (exactly what zero means, given
Andrew> the spec for to_xfer_memory(), is ``left as an exercise for
Andrew> the reader'' ;-) A wrapper function could then provide the
Andrew> semantics you're looking for.

This is possible if either the host or the target are comparing the
values, but when we're comparing checksums or CRCs all we know that
some data somewhere is different.  In that case, what value should
be returned?  Or are you suggesting the length is only interesting
for successful compares of a chunk so we'll know where to start the
next chunk?

Andrew> What should the target do if it isn't able to provide a more
Andrew> efficient compare mechanism?  My guess is leave the entry
Andrew> empty so that the higher level code is able to differentiate
Andrew> between an efficient target memory compare and a brutal memory
Andrew> read/compare.  That would suggest target_XXX_memory_p() and
Andrew> target_XXX_memory().

But is there a reason for higher level code to care how the compare is
implemented?  We could have target_XXX_memory check current_target->
to_XXX_memory --- if it's NULL, call that function otherwise a generic
implementation would be used.

        --jtc

-- 
J.T. Conklin
RedBack Networks
From shebs@cygnus.com Tue Nov 30 19:02:00 1999
From: Stan Shebs <shebs@cygnus.com>
To: mainguen@gabin.frcl.bull.fr
Cc: gdb@sourceware.cygnus.com
Subject: Re: Gdb target for kdb
Date: Tue, 30 Nov 1999 19:02:00 -0000
Message-id: <199912010302.TAA17555@andros.cygnus.com>
References: <199911231620.RAA29254@gabin.frcl.bull.fr>
X-SW-Source: 1999-q4/msg00379.html
Content-length: 1086

   Date: Tue, 23 Nov 1999 17:20:29 +0100
   From: Bernard Mainguenaud <mainguen@gabin.frcl.bull.fr>

   We intend to use gdb to debug a running Linux kernel connected
   to another Linux box via an asynchronous line. For this purpose,
   we are considering developping a new gdb target that interfaces
   with kdb. Has anyone ever tried to develop such a kdb target
   before ?

Not to my knowledge.  As Jim Blandy, you could pretend it's like a ROM
monitor and do a backend that way.  However, it would be better to add
a "GDB stub", which is a target-side implementation of the standard GDB
protocol.  Several of the Linux ports, such as for Sparc and Mips,
already have stubs built in; look for gdb_* in the arch-dependent
parts of the kernel.  The x86 port does not include a stub, at least
the last time I looked - supposedly Linus doesn't approve of debugging
stubs, but I haven't heard him actually say that, and it may just be
that no one has actually made the effort to get a stub in.  If so,
then this would be your chance to benefit other kernel developers...

								Stan