* Re: none
[not found] ` <199911251715.MAA09225@mescaline.gnu.org>
@ 1999-11-30 10:20 ` Jim Blandy
1999-12-01 0:21 ` ST(i) and MMj Eli Zaretskii
0 siblings, 1 reply; 8+ messages in thread
From: Jim Blandy @ 1999-11-30 10:20 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: gdb
> > 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: ST(i) and MMj
1999-11-30 10:20 ` none Jim Blandy
@ 1999-12-01 0:21 ` Eli Zaretskii
[not found] ` <npogca9tb8.fsf@zwingli.cygnus.com>
0 siblings, 1 reply; 8+ messages in thread
From: Eli Zaretskii @ 1999-12-01 0:21 UTC (permalink / raw)
To: jimb; +Cc: gdb
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 13607 bytes --]
(Note that I changed the subject: "none" seems inappropriate ;-)
> 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 could arrange for REGISTER_RAW_SIZE and REGISTER_BYTE to perform
the required mapping between %st(i) and %mmj using the current TOS.
> 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.
During that discussion I did agree that these registers should not be
treated as separate, but it seems we meant different things.
What I meant was that it is a Bad Idea to maintain separate data for
each one of these sets. In other words, if %st(3) corresponds to
%mm0, it is wrong to have GDB maintain a separate data buffer where
the contents of each one of these registers is held. The reason for
this is that it would be very hard to teach GDB and the
platform-specific code which data to use in each case, especially when
the user changes the values in these registers and you need to pass
the changed values to the debuggee.
But I don't see why cannot GDB _think_ about %st(X) and %mmY as being
separate registers while in reality they share the same data, if this
sharing is concealed behind REGISTER_BYTE and REGISTER_RAW_SIZE (and
possibly other functions/macros used to manipulate registers). What
are the specific problems with this scheme?
From ac131313@cygnus.com Wed Dec 01 00:39:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: jtc@redback.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: memory verify
Date: Wed, 01 Dec 1999 00:39:00 -0000
Message-id: <3844DE71.32797799@cygnus.com>
References: <5memd74iem.fsf@jtc.redbacknetworks.com> <384478F8.B079BDC2@cygnus.com> <5maenv4ehr.fsf@jtc.redbacknetworks.com> <38449CE7.26320160@cygnus.com> <5maenvcfqd.fsf@jtc.redbacknetworks.com>
X-SW-Source: 1999-q4/msg00385.html
Content-length: 1542
"J.T. Conklin" wrote:
>
> >>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
> >> 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.
>
> Andrew> Typically, yes. I can think of two cases:
> Andrew>
> Andrew> o a weak/broken CRC algorithm
> Andrew> which the user doesn't like.
> Andrew>
> Andrew> o Internal operations such as
> Andrew> program download that would exploit the CRC
> Andrew> when available. (ex program load could run
> Andrew> the crc before downloading each section. This
> Andrew> could cleanup the compare sections command.).
>
> I don't think the existance of a to_XXX_memory() vector function is
> enough of a hint for upper layers of GDB to decide whether to use it.
> For example, changing generic_load() to call to_XXX_memory() on each
> section to determine whether it is already loaded makes a lot of sense
> with targets with CRC-like verification. Those that implement it with
> a 'srecord verify'-like mechanism would lose (some ROM monitors have a
> command where a srecord stream is compared with the contents of memory
> instead of replacing the contents). But perhaps this is an argument
> against using that kind of implementation. Thoughts?
Bleuk :-)
That suggests one requirement on that method is that it be significantly
faster than a simple memory read :-)
Andrew
From ac131313@cygnus.com Wed Dec 01 00:57:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: "Brown, Rodney" <rodneybrown@pmsc.com>
Cc: "'gdb@sourceware.cygnus.com'" <gdb@sourceware.cygnus.com>
Subject: Re: memory verify
Date: Wed, 01 Dec 1999 00:57:00 -0000
Message-id: <3844E2C4.85B7A492@cygnus.com>
References: <9150F3E779F0D211BD370008C733141C38AA12@aus-msg-02.au.pmsc.com>
X-SW-Source: 1999-q4/msg00386.html
Content-length: 1387
> "Brown, Rodney" wrote:
>
> Depending how capable the stubs are, you could look at using Andrew
> Tridgewell's
> rsync algorithms. I think that uses CRCs to locate differences in
> files on
> different boxes to generate a delta file to update the file on one.
> This could allow the first difference idiom when run over large memory
> areas,
> without having to transmit the area over the wire.
Yes, I've had that in the back of my mind. Several aspects of a typical
embedded target make it less general then one would hope:
o the typical target has a weak CRC
(This suggests that perhaphs the check should
have a requirement that it be ``strong''.
How strong is an interesting question.
o rcync's performance depends heavily on the
stream nature of its remote connection.
The typical target uses an RPC like mechanism.
GDB's remote protocol is especially bad. The
overhead of requesting CRC's could quickly
mitigate any savings in avoiding downloads.
o remote targets are small and dumb with all the
the inteligence (?) and memory living in GDB.
Having said that, an embedded implementation of rsync would make for an
interesting performance boost when it came to re-loading memory. It
would definitly be a challenge to add an rsync session (it would be a
complex interaction than a simple exchange of packets) to GDB's remote
protocol.
enjoy,
Andrew
From ac131313@cygnus.com Wed Dec 01 01:55:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: David Golombek <daveg@maker.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Writing a new simulator
Date: Wed, 01 Dec 1999 01:55:00 -0000
Message-id: <3844F02D.EEFFEE84@cygnus.com>
References: <21vh6lj9mo.fsf@seattle143.maker.com>
X-SW-Source: 1999-q4/msg00387.html
Content-length: 2336
David Golombek wrote:
>
> I'm examining using the simulator code packaged with GDB for the basis
> of a new simulator project. I haven't seen much discussion here about
> the simulator packages, but haven't seen any other lists that might be
> appropriate. If there is another list, please direct me towards it.
> I've read through a fair bit of the existing code, and wanted to ask
> some questions to make sure my assumptions are correct.
>
> This work is for a new processor, to which I've already ported the
> Binutils, GDB, and Gas. This is for a 32bit processor with a lot of
> special functional units, which are memory mapped.
>
> 1) It seems that using either the mips or the v850 code as an example
> it the best bet, using the same igen framework that they use. T/F?
Yes (along with the tic80 and d30v). The more recent simulators have
tended to use igen and (more importantly) the sim/common framework.
Another alternative would be to write your own simulator generator and
just exploit the common framework.
> 2) Reading the igen source, as well as the code in 'common', is the
> only existing documentation on igen. T/F?
Unfortunatly also true. The main igen documentation is in its header
files where it describes the syntax of each file.
> 3) Is there a good "ramp-up" methodology for writing a simulator, or
> do I need to write very large parts of it before its useful at all?
> IE, are there some pieces that I can implement first to get at least a
> simulator that will run, if not do anything, so that I can do
> piecewise implementation?
Yes. Doing something like copying an existing sim directory (v850?
tic80?) and then chopping it back to nothing is a good strategy. Just
be ruthless. Simulators like the v850 were originally built using a
gencode program and now many years later still show some of that in
their internals.
> 4) Are there any mail archives or any discussion saved anywhere of the
> previous simulator implementations? Just to give me a heads up on
> potential pit-falls, etc., that i may run into.
To be honest, outside of direct discussions with people I work with,
you're the first person to ask!
There is an old PSIM mailing list / web site (
http://sourceware.cygnus.com/psim/ however that doesn't cover any of the
the more recent sim/ developemnt.
enjoy,
Andrew
From rok.papez@kiss.uni-lj.si Wed Dec 01 03:28:00 1999
From: Rok Papez <rok.papez@kiss.uni-lj.si>
To: gdb@sourceware.cygnus.com, gnu-gdb-bug@moderators.isc.org
Subject: Insight 19991116, gdbserver, fork() - always follows parent
Date: Wed, 01 Dec 1999 03:28:00 -0000
Message-id: <99120112265800.00878@Strader.home>
X-SW-Source: 1999-q4/msg00388.html
Content-length: 1361
Hi!
-> Problem description:
-----------------
Even if I explicitly set follow-fork-mode to child, insight still follows a
parent.
I've succesfully compiled "insight 19991116" but I have encountered the
following problems:
-----------------
(gdb) s
daemonize () at httpdial.c:105
105 rc=fork();
(gdb) show follow-fork-mode
Debugger response to a program call of fork or vfork is "child".
(gdb) n
Program received signal SIGSTOP, Stopped (signal).
0x804926f in daemonize () at httpdial.c:105
105 rc=fork();
(gdb) show follow-fork-mode
Debugger response to a program call of fork or vfork is "child".
(gdb) n
106 if (-1==rc) {
(gdb) p rc
$1 = 11730
-----------------
-> Platforms:
---------
Target is a Linux 2.2.13 (RH 6.0):
- gdbserver from insight-19991116
- debugging via TCP
Workstation is a Linux 2.2.13 (RH 6.0):
- running insight GUI (problem tested with insight -nw)
-> Questions:
----------
1.) Is the insight 19991116 version same as gdb 19991116 ?
2.) Can insight and/or gdb finally work with LinuxThreads? What about
gdbserver? Do new threads block when they get created ?
3.) How can I make gdb/insight/gdbserver follow a fork() && exec() ??
4.) Is it possible to compile into the programme a breakpoint (so when it is
run I could attach to it) - if yes - how to make it work with gdbserver.
--
best regards,
Rok Papez.
From rodneybrown@pmsc.com Wed Dec 01 06:03:00 1999
From: "Brown, Rodney" <rodneybrown@pmsc.com>
To: "'Andrew Cagney'" <ac131313@cygnus.com>, "Brown, Rodney" <rodneybrown@pmsc.com>
Cc: "'gdb@sourceware.cygnus.com'" <gdb@sourceware.cygnus.com>
Subject: RE: memory verify
Date: Wed, 01 Dec 1999 06:03:00 -0000
Message-id: <9150F3E779F0D211BD370008C733141C38AA13@aus-msg-02.au.pmsc.com>
X-SW-Source: 1999-q4/msg00389.html
Content-length: 2874
Title: RE: memory verify
The loop unrolled CRC-32 used in the info-zip tools (with a bit of extra
optimization) is 259 bytes i386 text space - but needs a 4*256 byte array.
Assuming that ultimate speed in CRC calculation isn't needed in the stub
then a nibble at a time varient - without loop unrolling should be possible
in < 259 bytes with a 4*16 = 64 byte array.
It should be possible to provide a CRC-32 in < 300 bytes (i386), if that
is strong enough.
Having just had a quick look at rsync, an MD4 checksum is being used - a cryptographic digest isn't it? If the rolling rsync checksum calculation
is small enough & you replaced the MD4 checksum with one or two 32-bit
CRC calculations you'd be able to do almost as well as with the MD4
checksum - but without the anti-tampering guarantees.
Note that adding another 32-bit CRC polynomial should only cost another
64 bytes of array or so.
-----Original Message-----
From: Andrew Cagney [ mailto:ac131313@cygnus.com ]
Sent: Wednesday, 1 December 1999 19:57
To: Brown, Rodney
Cc: 'gdb@sourceware.cygnus.com'
Subject: Re: memory verify
> "Brown, Rodney" wrote:
>
> Depending how capable the stubs are, you could look at using Andrew
> Tridgewell's
> rsync algorithms. I think that uses CRCs to locate differences in
> files on
> different boxes to generate a delta file to update the file on one.
> This could allow the first difference idiom when run over large memory
> areas,
> without having to transmit the area over the wire.
Yes, I've had that in the back of my mind. Several aspects of a typical
embedded target make it less general then one would hope:
       o      the typical target has a weak CRC
              (This suggests that perhaphs the check should
              have a requirement that it be ``strong''.
              How strong is an interesting question.
       o      rcync's performance depends heavily on the
              stream nature of its remote connection.
              The typical target uses an RPC like mechanism.
              GDB's remote protocol is especially bad. The
              overhead of requesting CRC's could quickly
              mitigate any savings in avoiding downloads.
       o      remote targets are small and dumb with all the
              the inteligence (?) and memory living in GDB.
Having said that, an embedded implementation of rsync would make for an
interesting performance boost when it came to re-loading memory. It
would definitly be a challenge to add an rsync session (it would be a
complex interaction than a simple exchange of packets) to GDB's remote
protocol.
       enjoy,
              Andrew
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Standard GDB Remote Protocol
[not found] ` <3845AB0E.3795D99E@ozemail.com.au>
@ 1999-12-01 15:43 ` Quality Quorum
1999-12-01 15:53 ` Stan Shebs
[not found] ` <5md7sql00o.fsf@jtc.redbacknetworks.com>
2 siblings, 0 replies; 8+ messages in thread
From: Quality Quorum @ 1999-12-01 15:43 UTC (permalink / raw)
To: Steven Johnson; +Cc: gdb
On Thu, 2 Dec 1999, Steven Johnson wrote:
> I am about to write a GDB Remote Stub, and I want to use the standard
> GDB Remote protocol for this.
>
> Can anyone point me at the Protocol specification for this? Or doesn't
> it exist?
>
> Ive looked everywhere I can think of and can find nothing documented
> about it, except references to the fact GDB has this standard Protocol.
>
> I Know i'll get the answer "Use the Source". But that is hardly
> appropriate for a Protocol. There are far more subtleties to Protocol
> Design and Implementation than can usually be gleaned from anyone's
> source code.
>
> If it doesn't exist, does anyone have any objections to a complete,
> formal, Protocol specification for the GDB Remote Protocol being
> created. (Note: here Im putting up my hand. If I have to reverse
> engineer it from the code, Im going to document it for my benefit
> anyway.)
>
> If it does exist, is it up-to-date?
Look at
http://sourceware.cygnus.com/gdb/onlinedocs/gdb_14.html#SEC115
It seems quite uptodate.
>
> If I need to create one, what format should I create it in? (i.e.,
> preferred document type).
>
> Steven Johnson
> Managing Director
> Neurizon Pty Ltd
>
Thanks,
Aleksey
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Standard GDB Remote Protocol
[not found] ` <3845AB0E.3795D99E@ozemail.com.au>
1999-12-01 15:43 ` Standard GDB Remote Protocol Quality Quorum
@ 1999-12-01 15:53 ` Stan Shebs
[not found] ` <5md7sql00o.fsf@jtc.redbacknetworks.com>
2 siblings, 0 replies; 8+ messages in thread
From: Stan Shebs @ 1999-12-01 15:53 UTC (permalink / raw)
To: sbjohnson; +Cc: gdb
Date: Thu, 02 Dec 1999 09:11:10 +1000
From: Steven Johnson <sbjohnson@ozemail.com.au>
Can anyone point me at the Protocol specification for this? Or doesn't
it exist?
Ive looked everywhere I can think of and can find nothing documented
about it, except references to the fact GDB has this standard Protocol.
As other people have pointed out, the complete spec is now part of the
main GDB manual. The 4.18 manual and earlier had a partial and
out-of-date description in section 13.4.14 "Communication protocol".
We've updated and expanded this section, and the description in the
manual is now the official specification for the protocol. So feel
free to rely on the manual, and if you find the description is lacking
or erroneous, please help us to correct it (or GDB); your effort will
be much appreciated by everybody.
Stan
From davidwilliams@ozemail.com.au Wed Dec 01 16:23:00 1999
From: David Williams <davidwilliams@ozemail.com.au>
To: "'gdb mail list'" <gdb@sourceware.cygnus.com>
Subject: remote debug of 68EZ328
Date: Wed, 01 Dec 1999 16:23:00 -0000
Message-id: <01BF3CB7.62CF55A0.davidwilliams@ozemail.com.au>
X-SW-Source: 1999-q4/msg00411.html
Content-length: 1311
Hi All,
I am still trying to ramp up on required knowledge to tackle this...
1. As far as I can tell, the remote protocol specifies communications
between a stub on the target system and GDB on host system. I assume that
there is some 68K specific code as part of GDB that communicates to stub on
target system - I am a little cloudy on this and would appreciate some
clarification.
2. Looking through the procotol & source for 68K-stub leads me to believe
that the 68K stub (and possibly all stubs) do not support hardware
breakpoints - they work by assuming code is running is RAM and op-code can
be substituted for trap instructions. Is this correct? If so then I cannot
use the remote protocol and a stub to support hardware breakpoints. What
other method is best. (I have received some responses to previous queries
on this subject but I still dont get it!)
3. Some people have mentioned insight to me. The suggestion is the Insight
may have slightly different (and possible later) sources for GDB component.
Is this true? I am interested in using a GUI with GDB and this sounds good.
My specific problems are that I am currently using win95 as my development
platform (yes I know) and dont know how this will affect development of
changes required to GDB (Insight).
TIA
David Williams
From shebs@cygnus.com Wed Dec 01 17:11:00 1999
From: Stan Shebs <shebs@cygnus.com>
To: davidwilliams@ozemail.com.au
Cc: gdb@sourceware.cygnus.com
Subject: Re: remote debug of 68EZ328
Date: Wed, 01 Dec 1999 17:11:00 -0000
Message-id: <199912020111.RAA01159@andros.cygnus.com>
References: <01BF3CB7.62CF55A0.davidwilliams@ozemail.com.au>
X-SW-Source: 1999-q4/msg00412.html
Content-length: 3890
From: David Williams <davidwilliams@ozemail.com.au>
Date: Thu, 2 Dec 1999 11:21:31 +1100
I am still trying to ramp up on required knowledge to tackle this...
1. As far as I can tell, the remote protocol specifies communications
between a stub on the target system and GDB on host system. I assume that
there is some 68K specific code as part of GDB that communicates to stub on
target system - I am a little cloudy on this and would appreciate some
clarification.
Yes, GDB has m68k-specific code that describes the architecture
in a somewhat abstract way, and only in as much detail as the debugger
needs. So for instance, there are bits saying that d0 is a 32-bit
register, a6 is the frame pointer, fp0 contains floats, etc. There
are also procedures to do things like decoding frames. All of this
code is common to all m68k systems, whether they're Apollos, Sun-3s,
Palms, whatever.
The remote protocol and its implementation are very generic. The
protocol is just a set of commands, like "$g#67", which says to
deliver all the registers. The size of the response is very different
from one system to another, but GDB just hopes for the best :-) and
dumps the blob of data into the array of registers. Once GDB has
acquired some register and memory data via the generic protocol, it
puts its m68k-specific code to work analyzing it, eventually resulting
in a reconstruction of your program's state.
So the purpose of your stub is simply to report program state and to
obey the commands (packets) sent to it by GDB. Since GDB has no other
means to contact the target system except the stub, it will pretty
much believe what your stub tells it. This suggests interesting
tricks that you can do - for instance, you could notice that a memory
write seems to be the depositing of a breakpoint instruction, and do
something else, like set a hardware breakpoint. As long as you're
telling GDB believable things, it will go along.
2. Looking through the procotol & source for 68K-stub leads me to believe
that the 68K stub (and possibly all stubs) do not support hardware
breakpoints - they work by assuming code is running is RAM and op-code can
be substituted for trap instructions. Is this correct? If so then I cannot
use the remote protocol and a stub to support hardware breakpoints. What
other method is best. (I have received some responses to previous queries
on this subject but I still dont get it!)
We've recently defined a 'Z' packet that is for the purpose of setting
hardware breakpoints. The generic m68k stub in the sources doesn't
use it, because any such code would be very specific to particular
systems. As you may have noticed, the stub file is public domain, not
even GPLed, because we want everybody to modify stubs so they'll fit
properly into the target system. As long as you conform to the
established protocol as defined in the manual, you can do whatever you
want.
3. Some people have mentioned insight to me. The suggestion is the Insight
may have slightly different (and possible later) sources for GDB component.
Is this true? I am interested in using a GUI with GDB and this sounds good.
My specific problems are that I am currently using win95 as my development
platform (yes I know) and dont know how this will affect development of
changes required to GDB (Insight).
Since you're already used to crashes, you won't be any worse off than
you are now... :-) Insight is just a tcl GUI extension to basic GDB.
The snapshot sources on sourceware are synced with the basic GDB
sources available at the same place, so you can use either as you
prefer. Building everything from scratch using cygwin on W95 usually
takes so long that something crashes before it finishes, but if you
reboot and continue building, you can eventually get to a working GDB.
Stan
From sbjohnson@ozemail.com.au Wed Dec 01 20:22:00 1999
From: Steven Johnson <sbjohnson@ozemail.com.au>
To: jtc@redback.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: Standard GDB Remote Protocol
Date: Wed, 01 Dec 1999 20:22:00 -0000
Message-id: <3845F45A.38EA29CF@ozemail.com.au>
References: <199911090706.CAA13120@zwingli.cygnus.com> <199911102246.RAA01846@mescaline.gnu.org> <npr9hi321d.fsf@zwingli.cygnus.com> <199911231303.IAA01523@mescaline.gnu.org> <npr9hg2a9t.fsf@zwingli.cygnus.com> <199911251715.MAA09225@mescaline.gnu.org> <npzovvc04o.fsf@zwingli.cygnus.com> <199912010821.DAA27130@mescaline.gnu.org> <npogca9tb8.fsf@zwingli.cygnus.com> <3845AB0E.3795D99E@ozemail.com.au> <5md7sql00o.fsf@jtc.redbacknetworks.com>
X-SW-Source: 1999-q4/msg00413.html
Content-length: 11909
"J.T. Conklin" wrote:
>
> Since you're putting up your hand, would you be willing to review the
> protocol spec and point out areas that are ambiguous, confusing, need
> revising, etc?
>
Following is a Hopefully Constructive Critique, of the GDB Remote
Protocol.
It is based on my First Read of the current online version of protocol
specification at:
http://sourceware.cygnus.com/gdb/onlinedocs/gdb_14.html
In my Critique, I am not posing real questions when I discuss subjects.
What I am doing is hi-lighting areas where I have questions in my own
mind, where I find the description of the protocol lacking. The answers
will probably be present in the current implemented code and stubs, and
I have not yet looked for those answers. Nor do I wish to, until my
initial analysis of the Protocol is complete. I do not wish to taint my
understanding of the written words of the protocol with Black Knowledge
gleaned from the source. Further my critique is not a criticism of the
hard work that people have already done to get the
documentation/GDB/protocol to this state. Further it is obvious from my
first read of the protocol is that it has undergone extensive evolution,
and I have taken this into consideration.
Any comments I make on ways to fix things are simply my attempt at
understanding the problem. They do not represent a request or proposal
to change anything in the protocol, they are presented as part of the
thought process I underwent when analysing the protocol. They also
indicate areas where I have concerns with my understanding of the
protocol as documented.
Packet Structure:
Simple structure, obviously originally designed to be able to be driven
manually from a TTY. (Hence it's ASCII nature.) However, the protocol
has evolved quite significantly and I doubt it could still be used very
efficiently from a TTY. That said, it still demarks frames effectively.
Sequence Numbers:
Definition of Sequence ID's needs work. Are they necessary? Are they
deprecated? What purpose do they currently serve within GDB? One would
imagine that they are used to allow GDB to handle retransmits from a
remote system. Reading between the lines, this is done to allow error
recovery when a transmission from target to host fails. Possible
sequence being:
<- $packet-data#checksum
-> +
-> $sequence-id:packet-data#checksum (checksum fails or receive timeout
halfway through packet).
<- -sequence-id
-> $sequence-id:packet-data#checksum
<- +sequence-id
When do the sequence-id's increment? Presumably on the successful
receipt of the +sequence-id acknowledgement.
If they increment on the successful acknowledgement, what happens if the
acknowledgement is in error? For example a framing error on the '+'. The
target would never see the successful acknowledgement and would not
increment it's sequence number.
So what if it doesn't? The +/- Ack/Nak mechanism should be amply
sufficient to allow retransmits of missed responses.
I can see little practical benefit in a sequence-id in the responses, as
it is currently documented. This is supported buy the comment within the
document: "Beyond that its meaning is poorly defined. GDB is not known
to output sequence-ids". This tends to indicate that the mechanism has
fallen out of use, Probably because it doesn't actually achieve
anything. If this is the case, it could be deprecated. However, I would
advocate not deprecating it from the protocol, because If they were sent
by GDB a current hole I believe is in the protocol could be plugged. (I
will discuss this hole later in this critique.)
Ack/Nak Mechanism:
Simple Ack/Nak Mechanism, using + and - Respectively. Also reflects the
simple ASCII basis of the protocol. My main concern with this system is
there is no documentation of timing. Usually Ack/Nak must be received
within a certain time frame, otherwise a Nak is assumed and a retransmit
proceeds. This is necessary, because it is possible for the Ack/Nak
character to be lost (however unlikely) on the line due to a data error.
I think there should be a general timing basis to the entire protocol to
tie up some potential communications/implementation problems.
The 2 primary timing constraints I see that are missing are:
Inter character times during a message transmission, and Ack/Nak
response times.
If a message is only half received, the receiver has no ability without
a timeout mechanism of generating a NAK signalling failed receipt. If
this occurs, and there is no timeout on ACK/NAK reception, the entire
comms stream could Hang. Transmitter is Hung waiting for an ACK/NAK and
the Receiver is Hung waiting for the rest of the message.
I would propose that something needs to be defined along the lines of:
Once the $ character for the start of a packet is transmitted, each
subsequent byte must be received within "n" byte transmission times.
(This would allow for varying comms line speeds). Or alternately a
global timeout on the whole message could be define one "$" (start
sentinel) is sent, the complete message must be received within "X"
time. I personally favour the inter character time as opposed to
complete message time as it will work with any size message, however the
complete message time restrict the maximum size of any one message (to
how many bytes can be sent at the maximum rate for the period). These
tiemouts do not need to be very tight, as they are merely for complete
failure recovery and a little delay there does not hurt much.
One possible timeout that would be easy to work with could be: Timeout
occurs 1 second after the last received byte.
For ACK/NAK I propose that something needs to be defined along the
lines: ACK/NAK must be received within X Seconds from transmission of
the end of the message, otherwise a NAK must be assumed.
There is no documentation of the recovery procedure, Does GDB retransmit
if its message is responded to with a NAK? If not, what does it do? How
is the target supposed to identify and handle retransmits from GDB.
What happens if something other than + or - is received when ACK/NAK is
expected. (For example $).
Identified Protocol Hole:
Lets look at the following abstract scenario (Text in brackets are
supporting comments):
<- $packet-data#checksum (Run Target Command)
-> + (Response is lost due to a line
error)
(Target runs for a very short period of time and then breaks).
-> $sequence-id:packet-data#checksum (Break Response - GDB takes as a
NAK, expecting a +, got a $).
<- $packet-data#checksum (GDB retransmits it's Run Target Command,
target restarts)
-> + (Response received OK by GDB).
(Target again starts running.)
In this scenario, it is shown that with the currently documented
mechanisms, it is possible for transmission errors to occur that
interfere with debugging. There was no mechanism for the target to
identify that GDB was re-transmitting and subsequently executed the same
operation twice. When GDB really only wanted to execute the command
once.
Its this sort of scenario that I imagine the sequence id's were created
for.
If GDB sent Sequence ID's then the scenario would be much different:
<- $ sequence-id:packet-data#checksum (Run Target Command)
-> + (Response
is lost due to a line error)
(Target runs for a very short period of time and then breaks).
-> $sequence-id:packet-data#checksum (Break Response - GDB takes as a
NAK, expecting a +, got a $).
<- $ sequence-id:packet-data#checksum (GDB retransmits it's Run Target
Command, with the same
sequence -id as in the original command)
(Target identifies the sequence-id as a retransmit.)
(Instead of performing the operation again, it simply re-responds with
the results obtained from the last command)
-> + (Response
received OK by GDB).
-> $sequence-id:packet-data#checksum (Break Response - GDB processes as
expected.)
(GDB then increments its sequence-id in preparation for the next
command.)
As an extra integrity check, the response sequence-id should be
identical to the request sequence-id. This would allow GDB to verify
that the response it is processing is properly paired with it's request.
Further, the target shouldn't require either ACK nor NAK. It should
process them properly if received, but otherwise process the received
packet, even if ACK/NAK was expected.
If this is the intent of sequence-id and it has fallen into disuse, then
to allow it's re-introduction at a later date, it could be documented
that if GDB sends a sequence-id, then the retransmit processing I've
documented here operates, otherwise the currently defined behaviour
operates, and that sequence-id is only sent by the target in responses
where they are present in the original GDB message. This would allow GDB
to probe if the target supports secure and recoverable message delivery
or not.
Run Length Encoding:
Is run length encoding supported in all packets, or just some packets?
(For example, not binary packets)
Why not allow lengths greater than 126? Or does this mean lengths
greater than 97 (as in 126-29)
If binary packets with 8 bit data can be sent, why not allow RLE to use
length also greater than 97. If the length maximum is really 126, then
this yields the character 0x9B which is 8 bits, wouldn't the maximum
length in this case be 226. Or is this a misprint?
Why are there 2 methods of RLE? Is it important for a Remote Target to
understand and process both, or is the "cisco encoding" a proprietary
extension of the GDB Remote protocol, and not part of the standard
implementation. The documentation of "cisco encoding" is confusing and
seems to conflict with standard RLE encoding. They appear to be mutually
exclusive. If they are both part of the protocol, how are they
distinguished when used?
Deprecated Messages:
Should an implementation of the protocol implement the deprecated
messages or not? What is the significance of the deprecated messages to
the current implementation?
Character Escaping:
The mechanism of Escaping the characters is not defined. Further it is
only defined as used by write mem binary. Wouldn't it be useful for
future expansion of the protocol to define Character Escaping as a
global feature of the protocol, so that if any control characters were
required to be sent, they could be escaped in a consistent manner across
all messages. Also, wouldn't the full list of escape characters be
$,#,+,-,*,0x7d. Otherwise, + & - might be processed inadvertently as ACK
or NAK. If this can't happen, then why must they be avoided in RLE? If
they are escaped across all messages, then that means they could be used
in RLE and not treated specially.
8/7 Bit protocol.
With the documentation of RAW Binary transfers, the protocol moves from
being a strictly 7 bit affair into being a 8 bit capable protocol. If
this is so, then shouldn't all the restrictions that are placed from the
7 bit protocol days be lifted to take advantage of the capabilities of
an 8 bit message stream. (RLE limitations, for example). Would anyone
seriously be using a computer that had a 7 bit limitation anymore
anyway? (At least a computer that would run GDB with remote debugging).
Thoughts on consistency and future growth:
Apply RLE as a feature of All messages. (Including binary messages, as
these can probably benefit significantly from it).
Apply the Binary Escaping mechanism as a feature of the packet that is
performed on all messages prior to transmission and immediately after
reception. Define an exhaustive set of "Characters to be escaped".
Introduce message timing constraints.
Properly define sequence-id and allow it to be used from GDB to make
communications secure and reliable.
Steven Johnson
Managing Director
Neurizon Pty Ltd
From jtc@redback.com Thu Dec 02 00:50:00 1999
From: jtc@redback.com (J.T. Conklin)
To: gdb@sourceware.cygnus.com
Subject: using '-x -' to read gdb script from stdin
Date: Thu, 02 Dec 1999 00:50:00 -0000
Message-id: <5miu2hhgkx.fsf@jtc.redbacknetworks.com>
X-SW-Source: 1999-q4/msg00414.html
Content-length: 991
I updated one of our year old GDB executables a week or so ago, and
was notified that one of the scripts used by SQA failed to work. I
tracked it down to the following bit of code that was ifdef'd out
earlier this year.
From main.c:
/* NOTE: I am commenting this out, because it is not clear
where this feature is used. It is very old and
undocumented. ezannoni: 1999-05-04 */
#if 0
if (cmdarg[i][0] == '-' && cmdarg[i][1] == '\0')
read_command_file (stdin);
else
#endif
The script invoked gdb like this:
echo list "*$addr" | $gdb -batch -x - $file | head -1
[ I know, I should be using addr2line. But this script was written
before addr2line existed. ]
Since all of our systems support /dev/stdin, I patched up our script
accordingly. But I wonder whether support for - should be reenabled.
Is there any reason why not?
--jtc
--
J.T. Conklin
RedBack Networks
From eliz@gnu.org Thu Dec 02 06:14:00 1999
From: Eli Zaretskii <eliz@gnu.org>
To: gdb@sourceware.cygnus.com
Cc: Andrew Cagney <ac131313@cygnus.com>, DJ Delorie <dj@delorie.com>
Subject: Re: -Wmissing-prototypes ...
Date: Thu, 02 Dec 1999 06:14:00 -0000
Message-id: <199912021414.JAA16068@mescaline.gnu.org>
References: <37E5E508.D56E054C@cygnus.com> <37CB6DBE.2083662F@cygnus.com>
X-SW-Source: 1999-q4/msg00415.html
Content-length: 8681
> My current list is:
>
> --enable-build-warnings=-Werror\
> ,-Wimplicit\
> ,-Wreturn-type\
> ,-Wcomment\
> ,-Wtrigraphs\
> ,-Wformat\
> ,-Wparentheses\
> ,-Wpointer-arith\
> ,-Wmissing-prototypes\
> ,-Woverloaded-virtual\
Here are the patches for go32-nat.c to allow it to compile with all
kinds of -Wfoo switches (I added switches beyond those mentioned above).
While working on this, I found out that defs.h redeclares several
library functions, like getenv, fclose and atof, because symbols like
GETENV_PROVIDED etc. aren't defined anywhere; this causes GCC to
complain (under the full list of warning options). What header should
define those for a particular host?
--- gdb/go32-nat.~17 Wed Dec 1 20:02:36 1999
+++ gdb/go32-nat.c Wed Dec 1 20:57:06 1999
@@ -29,6 +29,7 @@
#include "gdbcore.h"
#include "command.h"
#include "floatformat.h"
+#include "language.h"
#include <stdio.h> /* required for __DJGPP_MINOR__ */
#include <stdlib.h>
@@ -164,42 +165,47 @@
#define SOME_PID 42
static int prog_has_started = 0;
-static void print_387_status (unsigned short status, struct env387 *ep);
-static void go32_open (char *name, int from_tty);
-static void go32_close (int quitting);
-static void go32_attach (char *args, int from_tty);
-static void go32_detach (char *args, int from_tty);
-static void go32_resume (int pid, int step, enum target_signal siggnal);
-static int go32_wait (int pid, struct target_waitstatus *status);
-static void go32_fetch_registers (int regno);
-static void store_register (int regno);
-static void go32_store_registers (int regno);
+static void print_387_status (unsigned, struct env387 *);
+static void go32_open (char *, int);
+static void go32_close (int);
+static void go32_attach (char *, int);
+static void go32_detach (char *, int);
+static void go32_resume (int, int, enum target_signal);
+static int go32_wait (int, struct target_waitstatus *);
+static void go32_fetch_registers (int);
+static void store_register (int);
+static void go32_store_registers (int);
static void go32_prepare_to_store (void);
-static int go32_xfer_memory (CORE_ADDR memaddr, char *myaddr, int len,
- int write, struct target_ops *target);
-static void go32_files_info (struct target_ops *target);
+static int go32_xfer_memory (CORE_ADDR, char *, int,
+ int, struct target_ops *);
+static void go32_files_info (struct target_ops *);
static void go32_stop (void);
static void go32_kill_inferior (void);
-static void go32_create_inferior (char *exec_file, char *args, char **env);
+static void go32_create_inferior (char *, char *, char **);
static void cleanup_dregs (void);
static void go32_mourn_inferior (void);
static int go32_can_run (void);
static void ignore (void);
-static void ignore2 (char *a, int b);
-static int go32_insert_aligned_watchpoint (CORE_ADDR waddr, CORE_ADDR addr,
- int len, int rw);
-static int go32_remove_aligned_watchpoint (CORE_ADDR waddr, CORE_ADDR addr,
- int len, int rw);
-static int go32_handle_nonaligned_watchpoint (wp_op what, CORE_ADDR waddr,
- CORE_ADDR addr, int len, int rw);
+static int go32_insert_aligned_watchpoint (CORE_ADDR, CORE_ADDR, int, int);
+static int go32_remove_aligned_watchpoint (CORE_ADDR, CORE_ADDR, int, int);
+static int go32_handle_nonaligned_watchpoint (wp_op, CORE_ADDR, CORE_ADDR,
+ int, int);
static struct target_ops go32_ops;
static void go32_terminal_init (void);
static void go32_terminal_inferior (void);
static void go32_terminal_ours (void);
+int go32_insert_watchpoint (int, CORE_ADDR, int, int);
+int go32_remove_watchpoint (int, CORE_ADDR, int, int);
+int go32_region_ok_for_watchpoint (CORE_ADDR, int);
+CORE_ADDR go32_stopped_by_watchpoint (int, int);
+int go32_insert_hw_breakpoint (CORE_ADDR, CORE_ADDR);
+int go32_remove_hw_breakpoint (CORE_ADDR, CORE_ADDR);
+
+
static void
-print_387_status (unsigned short status, struct env387 *ep)
+print_387_status (unsigned status, struct env387 *ep)
{
int i;
int bothstatus;
@@ -221,7 +227,7 @@
print_387_status_word (ep->status);
}
- print_387_control_word (ep->control & 0xffff);
+ print_387_control_word ((unsigned)ep->control & 0xffff);
/* Other platforms say "last exception", but that's not true: the
FPU stores the last non-control instruction there. */
printf_unfiltered ("last FP instruction: ");
@@ -229,7 +235,8 @@
are not stored by the FPU (since these bits are the same for all
floating-point instructions). */
printf_unfiltered ("opcode %s; ",
- local_hex_string (ep->opcode ? (ep->opcode|0xd800) : 0));
+ local_hex_string (ep->opcode
+ ? (unsigned)(ep->opcode|0xd800) : 0));
printf_unfiltered ("pc %s:", local_hex_string (ep->code_seg));
printf_unfiltered ("%s; ", local_hex_string (ep->eip));
printf_unfiltered ("operand %s", local_hex_string (ep->operand_seg));
@@ -244,7 +251,7 @@
order, beginning with ST(0). Since we need to print them in
their physical order, we have to remap them. */
int regno = fpreg - top;
- long double val;
+ long double ldval;
if (regno < 0)
regno += 8;
@@ -272,9 +279,9 @@
printf_unfiltered ("%02x", ep->regs[regno][i]);
REGISTER_CONVERT_TO_VIRTUAL (FP0_REGNUM+regno, builtin_type_long_double,
- &ep->regs[regno], &val);
+ &ep->regs[regno], &ldval);
- printf_unfiltered (" %.19LG\n", val);
+ printf_unfiltered (" %.19LG\n", ldval);
}
}
@@ -381,7 +388,7 @@
TARGET_SIGNAL_QUIT, 0x7a,
TARGET_SIGNAL_ALRM, 0x78, /* triggers SIGTIMR */
TARGET_SIGNAL_PROF, 0x78,
- -1, -1
+ (enum target_signal)-1, -1
};
static void
@@ -420,7 +427,8 @@
if (siggnal != TARGET_SIGNAL_0 && siggnal != TARGET_SIGNAL_TRAP)
{
- for (i = 0, resume_signal = -1; excepn_map[i].gdb_sig != -1; i++)
+ for (i = 0, resume_signal = -1;
+ excepn_map[i].gdb_sig != (enum target_signal)-1; i++)
if (excepn_map[i].gdb_sig == siggnal)
{
resume_signal = excepn_map[i].djgpp_excepno;
@@ -439,7 +447,7 @@
{
int i;
unsigned char saved_opcode;
- unsigned long INT3_addr;
+ unsigned long INT3_addr = 0L;
int stepping_over_INT = 0;
a_tss.tss_eflags &= 0xfeff; /* reset the single-step flag (TF) */
@@ -594,14 +602,14 @@
static void
go32_store_registers (int regno)
{
- int r;
+ unsigned r;
if (regno >= 0)
store_register (regno);
else
{
for (r = 0; r < sizeof (regno_mapping) / sizeof (regno_mapping[0]); r++)
- store_register (r);
+ store_register ((int)r);
}
}
@@ -611,12 +619,12 @@
}
static int
-go32_xfer_memory (CORE_ADDR memaddr, char *myaddr, int len, int write,
+go32_xfer_memory (CORE_ADDR memaddr, char *myaddr, int len, int to_write,
struct target_ops *target)
{
- if (write)
+ if (to_write)
{
- if (write_child (memaddr, myaddr, len))
+ if (write_child (memaddr, myaddr, (unsigned)len))
{
return 0;
}
@@ -627,7 +635,7 @@
}
else
{
- if (read_child (memaddr, myaddr, len))
+ if (read_child (memaddr, myaddr, (unsigned)len))
{
return 0;
}
@@ -820,12 +828,13 @@
#define SHOW_DR(text,len) \
do { \
if (!getenv ("GDB_SHOW_DR")) break; \
- fprintf(stderr,"%08x %08x ",edi.dr[7],edi.dr[6]); \
- fprintf(stderr,"%08x %d %08x %d ", \
+ fprintf(stderr,"%08lx %08lx ",edi.dr[7],edi.dr[6]); \
+ fprintf(stderr,"%08lx %d %08lx %d ", \
edi.dr[0],dr_ref_count[0],edi.dr[1],dr_ref_count[1]); \
- fprintf(stderr,"%08x %d %08x %d ", \
+ fprintf(stderr,"%08lx %d %08lx %d ", \
edi.dr[2],dr_ref_count[2],edi.dr[3],dr_ref_count[3]); \
- fprintf(stderr,(len)?"(%s:%d)\n":"(%s)\n",#text,len); \
+ if (len) fprintf(stderr,"(%s:%d)\n",#text,len); \
+ else fprintf(stderr,"(%s)\n",#text); \
} while (0)
#else
#define SHOW_DR(text,len) do {} while (0)
@@ -861,7 +870,7 @@
int len, int rw)
{
int i;
- int read_write_bits, len_bits;
+ unsigned read_write_bits, len_bits;
/* Values of rw: 0 - write, 1 - read, 2 - access (read and write).
However, x86 doesn't support read-only data breakpoints. */
@@ -992,7 +1001,7 @@
int len, int rw)
{
int i;
- int read_write_bits, len_bits;
+ unsigned read_write_bits, len_bits;
/* Values of rw: 0 - write, 1 - read, 2 - access (read and write).
However, x86 doesn't support read-only data breakpoints. */
@@ -1105,9 +1114,6 @@
go32_insert_hw_breakpoint (CORE_ADDR addr, CORE_ADDR shadow)
{
int i;
- int read_write_bits, len_bits;
- int free_debug_register;
- int register_number;
/* Look for an occupied debug register with the same address and the
same RW and LEN definitions. If we find one, we can use it for
From gatliff@haulpak.com Thu Dec 02 06:43:00 1999
From: William Gatliff <gatliff@haulpak.com>
To: gdb@sourceware.cygnus.com
Subject: Re: Standard GDB Remote Protocol
Date: Thu, 02 Dec 1999 06:43:00 -0000
Message-id: <384685A7.15184EB1@haulpak.com>
References: <199911090706.CAA13120@zwingli.cygnus.com> <199911102246.RAA01846@mescaline.gnu.org> <npr9hi321d.fsf@zwingli.cygnus.com> <199911231303.IAA01523@mescaline.gnu.org> <npr9hg2a9t.fsf@zwingli.cygnus.com> <199911251715.MAA09225@mescaline.gnu.org> <npzovvc04o.fsf@zwingli.cygnus.com> <199912010821.DAA27130@mescaline.gnu.org> <npogca9tb8.fsf@zwingli.cygnus.com> <3845AB0E.3795D99E@ozemail.com.au> <5md7sql00o.fsf@jtc.redbacknetworks.com> <3845F45A.38EA29CF@ozemail.com.au>
X-SW-Source: 1999-q4/msg00416.html
Content-length: 5911
Steven Johnson wrote:
> Packet Structure:
>
> Simple structure, obviously originally designed to be able to be driven
> manually from a TTY. (Hence it's ASCII nature.) However, the protocol has
> evolved quite significantly and I doubt it could still be used very
> efficiently from a TTY.
True, but it can still be *monitored* quite effectively with a TTY, and
simple things like a ? query are still possible. If I'm using a TTY then
I'm desperate anyway, so I'm willing to put up with a little pain. Go to a
non-ASCII protocol, however, and the TTY option is right out altogether, no
matter how desperate I am!
If efficiency/throughput is a problem, then go to ethernet. At 10/100Mbps,
even the overhead of ASCII isn't a problem for most targets I can think of.
> I think there should be a general timing basis to the entire protocol to
> tie up some potential communications/implementation problems.
The RSP's lack of timing requirements is an asset, as far as I'm
concerned. See below.
> If a message is only half received, the receiver has no ability without a
> timeout mechanism of generating a NAK signalling failed receipt. If this
> occurs, and there is no timeout on ACK/NAK reception, the entire comms
> stream could Hang. Transmitter is Hung waiting for an ACK/NAK and the
> Receiver is Hung waiting for the rest of the message.
This is something that a stub can handle itself, as a self-protection
measure, without changing the RSP.
A debugging stub running on production hardware would probably need to do
this anyway, while a lab/development system could tolerate a hang (concerns
with rotating machinery, etc. notwithstanding). So, I don't see any reason
to create requirements, because they're likely to be so target-specific
that you'll never get good agreement on what they should be, and therefore
there will not be any uniform implementations.
In my opinion, a debugging stub is the responsible party for the safety of
a debugging target, because it alone can decide what to do if it thinks
that gdb has "gone away" unexpectedly (line noise, PC/protocol hang,
etc.). When this is done, nobody cares if gdb hangs, because it doesn't
necessarily cause problems for the target.
From that perspective, it is clear to me that a debugging stub will have to
do whatever it needs to do to protect itself and the target, regardless of
what the RSP says.
So the mission to beef up the RSP in the way you suggest seems
counterproductive. In the best case, you'll drive the need for gdb
enhancements that won't benefit most people (i.e. timing requirements that
are so loose that targets cannot depend on them); in the worst case, you'll
create gdb behaviors that are incompatible with certain types of targets
(i.e. timing requirements that are so tight that targets and hosts can't
implement them).
> I would propose that something needs to be defined along the lines of:
>
> Once the $ character for the start of a packet is transmitted, each
> subsequent byte must be received within "n" byte transmission times.
> (This would allow for varying comms line speeds). Or alternately a global
> timeout on the whole message could be define one "$" (start sentinel) is
> sent, the complete message must be received within "X" time. I personally
> favour the inter character time as opposed to complete message time as it
> will work with any size message, however the complete message time
> restrict the maximum size of any one message (to how many bytes can be
> sent at the maximum rate for the period). These tiemouts do not need to
> be very tight, as they are merely for complete failure recovery and a
> little delay there does not hurt much.
>
> One possible timeout that would be easy to work with could be: Timeout
> occurs 1 second after the last received byte.
>
> For ACK/NAK I propose that something needs to be defined along the lines:
> ACK/NAK must be received within X Seconds from transmission of the end of
> the message, otherwise a NAK must be assumed.
Good suggestions, but I would prefer that these be general stub design
guidelines that aren't enforced by gdb. Let gdb be as flexible as
possible, so that it will work with super-smart stubs that do all the
timing stuff properly, as well as stubs that are minimally written.
Gdb is supposed to be a debugging aid; I would prefer that all the protocol
stuff not get in the way of its fundamental mission.
Also, how do you measure byte times on most debugging hosts, particularly
at 115K (my bit rate of choice) and higher? Such a specification sounds
easy, but an implementation isn't likely to be portable.
And finally, consider the case where an M command is really writing to
flash, and the debugging target gets busy erasing flash sectors (which can
take longer than a second in some cases)? If gdb retries, things may get
confusing.
> There is no documentation of the recovery procedure, Does GDB retransmit
> if its message is responded to with a NAK? If not, what does it do? How
> is the target supposed to identify and handle retransmits from GDB.
> What happens if something other than + or - is received when ACK/NAK is
> expected. (For example $).
From my own experience, remote.c is kinda fragile where stuff like this is
concerned. I had been intending to look into this myself next year, but by
then someone else will have certainly beaten me to it. I think some
improvements have already been made.
> Character Escaping: The mechanism of Escaping the characters is not
> defined. Further it is only defined as used by write mem binary.
That's because this is the only place where it is needed, AFAIK. And,
since X is optional (and support for it is detected automatically by gdb),
that means that I don't have to implement it if I don't want to. Bonus for
super-minimal stubs.
b.g.
--
William A. Gatliff
Senior Design Engineer
Komatsu Mining Systems
To teach is to learn.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Standard GDB Remote Protocol
[not found] ` <38470CC1.1B0E5C27@ozemail.com.au>
@ 1999-12-03 5:41 ` Bill Gatliff
0 siblings, 0 replies; 8+ messages in thread
From: Bill Gatliff @ 1999-12-03 5:41 UTC (permalink / raw)
To: gdb
Steven:
[snip snip]
Sounds like we agree more than we disagree. *whew*! :^)
> Yes, here's the issue. The document is completely lacking in stub
> implementation guidelines. IMHO, there needs to be a section of the
> protocol (or comments throughout it) that give this sort of information
> and advice to implementers of stubs.
Here's where a good reference stub library might be of use. (As instructive as
they are, I'm not sure the example stubs qualify in this department).
I'm working on such a beast, mostly because I routinely work with more than one
type of embedded processor. I have it done for the SH-2 (although I'm still
adding some exception handling), someone is helping with an ARM port, and Dave
Williams is looking at for a 68k port.
If anyone else was interested in the code, I would be happy to see it placed on a
Cygnus web/cvs site somewhere--- at the moment, however, I don't have the
resources or time to set something up myself.
> Again I agree with this. I was making the observation that Character
> Escaping is likely to become more prevalent as the protocol evolves. To
> define character escaping around one message could create a situation
> where different messages that require it implement different mechanisms.
Escaping seems to be most needed in messages with binary content, of which there
are few. Hopefully this will continue to be the case, but since programs are
getting bigger all the time, X and similar messages may become a necessity...
:^( In that situation, standardized escaping would be a real bonus.
> What would probably be more appropriate is to state how escaping is
> performed where required as part of the base level protocol. Then in the
> message put a statement like, "This message contains binary data and
> must be Escaped using the standard escaping mechanism defined above".
Right. If you've got to do it, at least make it consistent.
> This way if you don't implement any of those messages, you don't need to
> implement Escaping. But it advantageous in that it defines how escaping
> will be used in any/all messages that require it. I think the same
> should be said for RLE.
Agreed. Maybe RLE and escaping go at the level that $#+- are at, instead of on a
per-message basis, so the protocol will allow you to RLE or escape *any*
message. I think that's what you're saying, anyway...
> Maybe each message needs a check list that
> states what features it may use like this:
>
> My new Message U My comments on this message
Or maybe a new kind of query? I'm not sure I like that approach, but queries may
have been created with stuff like this in mind. With only slightly more than a
year of gdb under my belt, however, I don't have enough experience to say.
Perhaps someone else does?
b.g.
--
William A. Gatliff
Senior Design Engineer
Komatsu Mining Systems
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Standard GDB Remote Protocol
[not found] ` <3845F45A.38EA29CF@ozemail.com.au>
[not found] ` <384685A7.15184EB1@haulpak.com>
@ 1999-12-07 14:13 ` J.T. Conklin
1 sibling, 0 replies; 8+ messages in thread
From: J.T. Conklin @ 1999-12-07 14:13 UTC (permalink / raw)
To: Steven Johnson; +Cc: gdb
>>>>> "Steven" == Steven Johnson <sbjohnson@ozemail.com.au> writes:
>> Since you're putting up your hand, would you be willing to review the
>> protocol spec and point out areas that are ambiguous, confusing, need
>> revising, etc?
Steven> Following is a Hopefully Constructive Critique, of the GDB Remote
Steven> Protocol.
Many thanks.
I realize I'm late in this response, but I read your message as soon
as it came in. I was quite pleased that you found so many issues so
quickly.
Steven> Packet Structure:
Steven> Simple structure, obviously originally designed to be able to be driven
Steven> manually from a TTY. (Hence it's ASCII nature.) However, the protocol
Steven> has evolved quite significantly and I doubt it could still be used very
Steven> efficiently from a TTY. That said, it still demarks frames effectively.
I'm a bit more pessimistic. I believe that framing was effective in
the original protocol (although I would have put the checksum inside
the packet delimeters); but recent changes have muddied the distinc-
tion between the debug protocol and the data link layer to the point
where they are now inseparable. I think this is most unfortunate.
Steven> Sequence Numbers:
Steven> Definition of Sequence ID's needs work. Are they necessary? Are they
Steven> deprecated? What purpose do they currently serve within GDB? One would
Steven> imagine that they are used to allow GDB to handle retransmits from a
Steven> remote system. Reading between the lines, this is done to allow error
Steven> recovery when a transmission from target to host fails. Possible
Steven> sequence being:
I'm sure that you understand that we have to document the protocol as
it is, rather than how we would like it to be. The protocol allows a
good deal of flexibility in adding new commands, which GDB can use by
probing the remote stub. This allows the protocol to evolve without
requiring all existing stubs to be changed. Unfortunately, there is
not a similar ability to change the data-link layer. The cases where
we've done so (RLE, binary write) have had unfortunate consequences
that were not realized until too late.
That's a long and roundabout way of saying that sequence numbers have
limited usefulness, and it will be difficult if not impossible to fix
them.
All a stub does is append the sequence number to the ack. GDB could
use this to ensure that it's not misinterpreting the ACK for another
packet or a '+' found within a packet, but it can't assume that stubs
will reject subsequent packets with the same sequence number (duplic-
ate packets).
Another problem, not with the spec but with the implementation is that
naks to packets with sequence numbers should also append the sequence
number, but none of the sample stubs do this.
Steven> <- $packet-data#checksum
Steven> -> +
Steven> -> $sequence-id:packet-data#checksum (checksum fails or receive timeout
Steven> halfway through packet).
Steven> <- -sequence-id
Steven> -> $sequence-id:packet-data#checksum
Steven> <- +sequence-id
Steven> When do the sequence-id's increment? Presumably on the successful
Steven> receipt of the +sequence-id acknowledgement.
Steven> If they increment on the successful acknowledgement, what happens if the
Steven> acknowledgement is in error? For example a framing error on the '+'. The
Steven> target would never see the successful acknowledgement and would not
Steven> increment it's sequence number.
Steven> So what if it doesn't? The +/- Ack/Nak mechanism should be amply
Steven> sufficient to allow retransmits of missed responses.
Steven> I can see little practical benefit in a sequence-id in the responses, as
Steven> it is currently documented. This is supported buy the comment within the
Steven> document: "Beyond that its meaning is poorly defined. GDB is not known
Steven> to output sequence-ids". This tends to indicate that the mechanism has
Steven> fallen out of use, Probably because it doesn't actually achieve
Steven> anything. If this is the case, it could be deprecated. However, I would
Steven> advocate not deprecating it from the protocol, because If they were sent
Steven> by GDB a current hole I believe is in the protocol could be plugged. (I
Steven> will discuss this hole later in this critique.)
Steven> Ack/Nak Mechanism:
Steven> Simple Ack/Nak Mechanism, using + and - Respectively. Also
Steven> reflects the simple ASCII basis of the protocol. My main
Steven> concern with this system is there is no documentation of
Steven> timing. Usually Ack/Nak must be received within a certain time
Steven> frame, otherwise a Nak is assumed and a retransmit
Steven> proceeds. This is necessary, because it is possible for the
Steven> Ack/Nak character to be lost (however unlikely) on the line
Steven> due to a data error. I think there should be a general timing
Steven> basis to the entire protocol to tie up some potential
Steven> communications/implementation problems.
Yes, the protocol should talk about timeouts. IMHO the timeouts need
to be presented as variables rather than absolutes, as the acceptable
timeout will vary greatly depending on situation.
There is GDB variable 'remotetimeout' which is used for timeouts, but
there are more than one timeout should distinguish even if GDB and the
stubs do not. Two that come to mind are the time between a packet is
sent and an ack/nak is sent in response, and the time between a ack'd
command is sent and a response is received.
Steven> Once the $ character for the start of a packet is transmitted, each
Steven> subsequent byte must be received within "n" byte transmission times.
Steven> (This would allow for varying comms line speeds). Or alternately a
Steven> global timeout on the whole message could be define one "$" (start
Steven> sentinel) is sent, the complete message must be received within "X"
Steven> time. I personally favour the inter character time as opposed to
Steven> complete message time as it will work with any size message,
As above, rather than come up with a heuristic like n * bit rate, or n
ticks (in whatever unit) per packet, I believe that GDB must provide a
variable (or variables) for timeouts. For example, both of the above
would fail with a high latency connection, perhaps commands to a mars
probe...
Steven> One possible timeout that would be easy to work with could be:
Steven> Timeout occurs 1 second after the last received byte.
This might lose for very low bandwidth connections, perhaps commands
to submerged submarines.
Steven> For ACK/NAK I propose that something needs to be defined along
Steven> the lines: ACK/NAK must be received within X Seconds from
Steven> transmission of the end of the message, otherwise a NAK must
Steven> be assumed.
Steven> There is no documentation of the recovery procedure, Does GDB
Steven> retransmit if its message is responded to with a NAK? If not,
Steven> what does it do? How is the target supposed to identify and
Steven> handle retransmits from GDB.
GDB retransmits commands 3 times and gives up. This is a hardcoded
constant --- there is no 'remoteretries' variable.
Steven> What happens if something other than + or - is received when
Steven> ACK/NAK is expected. (For example $).
A '$' is assumed to be an old response. It then calls getpkt() to eat
up the packet. Even if it is a packet, getpkt() is probably going to
fail because the '$' has already been read.
Any other character is considered to be junk and is discarded. There
is no timeout so if the stub continuously spews junk, the connection
will hang.
Steven> If this is the intent of sequence-id and it has fallen into
Steven> disuse, then to allow it's re-introduction at a later date, it
Steven> could be documented that if GDB sends a sequence-id, then the
Steven> retransmit processing I've documented here operates, otherwise
Steven> the currently defined behaviour operates, and that sequence-id
Steven> is only sent by the target in responses where they are present
Steven> in the original GDB message. This would allow GDB to probe if
Steven> the target supports secure and recoverable message delivery or
Steven> not.
I'm a bit fuzzy here. It's not clear how GDB can probe whether the
stub supports a reliable transport, since there are so many stubs in
the field that respond with an ack with an appended sequence number
after receiving a packet with a sequence number.
Steven> Run Length Encoding:
Steven> Is run length encoding supported in all packets, or just some packets?
Steven> (For example, not binary packets)
It's supported on all packets from the target to GDB. It's unfortunate
that this isn't symetric, because it would be most useful in one of the
most issued commands: write all registers.
Steven> Why not allow lengths greater than 126? Or does this mean lengths
Steven> greater than 97 (as in 126-29)
The run length is encoded as a printable ASCII value, so the run
length should not be greater than 97.
Steven> If binary packets with 8 bit data can be sent, why not allow
Steven> RLE to use length also greater than 97. If the length maximum
Steven> is really 126, then this yields the character 0x9B which is 8
Steven> bits, wouldn't the maximum length in this case be 226. Or is
Steven> this a misprint?
Packets with 8 bit values are still problematic. Even the probe GDB
does to determine whether the binary memory write command exists is
no guarentee that all possible values can be transmitted.
Steven> Why are there 2 methods of RLE? Is it important for a Remote
Steven> Target to understand and process both, or is the "cisco
Steven> encoding" a proprietary extension of the GDB Remote protocol,
Steven> and not part of the standard implementation. The documentation
Steven> of "cisco encoding" is confusing and seems to conflict with
Steven> standard RLE encoding. They appear to be mutually
Steven> exclusive. If they are both part of the protocol, how are they
Steven> distinguished when used?
Some companies have made their own modifications to the remote protocol
without consulting or working with the GDB maintainers. In some cases,
they later decide to contribute their extensions. This is the case of
the Cisco remote protocol extensions. GDB distinguishes the remote
protocol and the Cisco varient by treating them as separate protocols
that happen to share a lot of code.
I still think the integration of Cisco's changes were not in the best
interest of GDB. But one thing I think they did right was their
implementation of RLE. At the expense of one extra character to
express the run length, 256 bytes can be represented.
Steven> Deprecated Messages:
Steven> Should an implementation of the protocol implement the deprecated
Steven> messages or not? What is the significance of the deprecated messages
Steven> to the current implementation?
I think not. Commands have been depricated because:
* they were insufficently specified
* were never implemented in a released GDB and/or sample debug stubs
* were replaced by a better way of doing things.
* etc.
In the table of comands, I'd prefer that instead of some commands be
marked 'optional', that the required commands (g/G/m/M/c) be marked
required.
Steven> Character Escaping:
Steven> The mechanism of Escaping the characters is not
Steven> defined. Further it is only defined as used by write mem
Steven> binary. Wouldn't it be useful for future expansion of the
Steven> protocol to define Character Escaping as a global feature of
Steven> the protocol, so that if any control characters were required
Steven> to be sent, they could be escaped in a consistent manner
Steven> across all messages. Also, wouldn't the full list of escape
Steven> characters be $,#,+,-,*,0x7d. Otherwise, + & - might be
Steven> processed inadvertently as ACK or NAK. If this can't happen,
Steven> then why must they be avoided in RLE? If they are escaped
Steven> across all messages, then that means they could be used in RLE
Steven> and not treated specially.
IMO the problem with character stuffing is that it's happining at the
protocol layer instead of the data link layer. You're right that the
full list of characters should include '$', '#', '+', and '-'.
Although GDB -> target RLE is not performed, '*' should be probably
done done in case it is (or binary memory read) is implemented.
In addition, I'd include characters with values 0-31 and 128-159 to
avoid problems with serial links that don't handle control characters.
Perhaps with some sort of data link negotiation that would open up
larger windows.
Another benefit with doing character stuffing at the data link layer
is that it avoids dealing with variable length packets at the protocol
layer.
But I don't know how we could fix this now.
Steven> 8/7 Bit protocol.
Steven> With the documentation of RAW Binary transfers, the protocol moves from
Steven> being a strictly 7 bit affair into being a 8 bit capable protocol. If
Steven> this is so, then shouldn't all the restrictions that are placed from the
Steven> 7 bit protocol days be lifted to take advantage of the capabilities of
Steven> an 8 bit message stream. (RLE limitations, for example). Would anyone
Steven> seriously be using a computer that had a 7 bit limitation anymore
Steven> anyway? (At least a computer that would run GDB with remote debugging).
I'm more concerned with the other side than the GDB side. I can
imagine a target that could only reasonably support a 7 bit channel.
Steven> Thoughts on consistency and future growth:
Steven> Apply RLE as a feature of All messages. (Including binary messages, as
Steven> these can probably benefit significantly from it).
Steven> Apply the Binary Escaping mechanism as a feature of the packet that is
Steven> performed on all messages prior to transmission and immediately after
Steven> reception. Define an exhaustive set of "Characters to be escaped".
Steven> Introduce message timing constraints.
Steven> Properly define sequence-id and allow it to be used from GDB to make
Steven> communications secure and reliable.
These are all great, but I'm not sure how much can been within the
confines of the existing protocol.
--jtc
--
J.T. Conklin
RedBack Networks
From jtc@redback.com Tue Dec 07 14:53:00 1999
From: jtc@redback.com (J.T. Conklin)
To: Bill Gatliff <gatliff@haulpak.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Standard GDB Remote Protocol
Date: Tue, 07 Dec 1999 14:53:00 -0000
Message-id: <5miu2az7lb.fsf@jtc.redbacknetworks.com>
References: <199911090706.CAA13120@zwingli.cygnus.com> <199911102246.RAA01846@mescaline.gnu.org> <npr9hi321d.fsf@zwingli.cygnus.com> <199911231303.IAA01523@mescaline.gnu.org> <npr9hg2a9t.fsf@zwingli.cygnus.com> <199911251715.MAA09225@mescaline.gnu.org> <npzovvc04o.fsf@zwingli.cygnus.com> <199912010821.DAA27130@mescaline.gnu.org> <npogca9tb8.fsf@zwingli.cygnus.com> <3845AB0E.3795D99E@ozemail.com.au> <5md7sql00o.fsf@jtc.redbacknetworks.com> <3845F45A.38EA29CF@ozemail.com.au> <384685A7.15184EB1@haulpak.com> <38470CC1.1B0E5C27@ozemail.com.au> <3847C872.55287A40@haulpak.com>
X-SW-Source: 1999-q4/msg00467.html
Content-length: 2355
>>>>> "Bill" == Bill Gatliff <gatliff@haulpak.com> writes:
>> This way if you don't implement any of those messages, you don't need to
>> implement Escaping. But it advantageous in that it defines how escaping
>> will be used in any/all messages that require it. I think the same
>> should be said for RLE.
Bill> Agreed. Maybe RLE and escaping go at the level that $#+- are at,
Bill> instead of on a per-message basis, so the protocol will allow you
Bill> to RLE or escape *any* message. I think that's what you're saying,
Bill> anyway...
Had binary data been quoted at the data link layer, the implementation
would have been a lot simpler and likely more robust. I wish I would
have noticed this back when I objected to binary write being added as
4.18 was being released.
Unfortunately, I can't see how we can do this in a compatible manner.
The character stuffing increases the packet length. The memory write
command compensates by reducing the length of the data being written,
resulting in a packet < PBUFSIZ.
Ideally you don't want the protocol layer to know these kind of
details --- only the link layer MTU. This would work fine if both GDB
and the stub did quoting at the link layer. Gdb could send a packet
that, after stuffing, was larger than PBUFSIZ. But this would not be
a problem because the new stub would un-stuff (and un-rle) packets as
they are received. But if such a GDB was communicating to a stub that
didn't unstuff until the 'X' command was processed, packet buffers may
overflow.
>> Maybe each message needs a check list that
>> states what features it may use like this:
>>
>> My new Message U My comments on this message
Bill> Or maybe a new kind of query? I'm not sure I like that
Bill> approach, but queries may have been created with stuff like this
Bill> in mind. With only slightly more than a year of gdb under my
Bill> belt, however, I don't have enough experience to say. Perhaps
Bill> someone else does?
Perhaps we could have a query command used determine data link layer
capabilities. It would have to be issued at the initial connection,
and would have to be issued with the least-common-denominator 7 bit
query, no-rle, framing. It's a bit ugly... I don't like it... but
it probably could be made to work.
--jtc
--
J.T. Conklin
RedBack Networks
From jimb@cygnus.com Tue Dec 07 15:07:00 1999
From: Jim Blandy <jimb@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: i386 info float
Date: Tue, 07 Dec 1999 15:07:00 -0000
Message-id: <199912072307.SAA02179@zwingli.cygnus.com>
X-SW-Source: 1999-q4/msg00468.html
Content-length: 1367
We were notified yesterday that the FSF had received the copyright
papers for Mark's `info float' command, so it's in the sources now.
It should appear in the next snapshot. Thanks very much, Mark!
Persons of proper upbringing will be shocked to learn that there are
no less than eight distinct implementations of `info float' for the
x86. Now, the Sequent machines do have the Weitek FPU, so one could
plausibly argue that they merit their own `info float' command. But
they don't. (As far as I can tell.) So the duplication is completely
gratuitous.
They are as follows:
The one we want to keep:
i387-tdep.c:i387_float_info
Maintained platforms:
go32-nat.c:i386_go32_float_info (Eli's bailiwick)
i386gnu-nat.c:i386_mach3_float_info (Mark's bailiwick)
i386b-nat.c:i386_float_info (used on all BSD's; any takers?)
i386v-nat.c:i386_float_info (#if 0'd out)
Unmaintained platforms (as far as I know):
i386m3-nat.c:i386_mach3_float_info (unmaintained)
i386aix-nat.c:i386_float_info (unmaintained)
symm-nat.c:i386_float_info (unmaintained)
I'm going to delete the definition from i386v-nat.c. As far as I
know, there are no BSD GDB folks participating in this list, so we'll
just have to wait until someone speaks up about them. So, once Eli and
Mark have taken care of their targets, we're basically done.
From jtc@redback.com Tue Dec 07 15:33:00 1999
From: jtc@redback.com (J.T. Conklin)
To: William Gatliff <gatliff@haulpak.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Standard GDB Remote Protocol
Date: Tue, 07 Dec 1999 15:33:00 -0000
Message-id: <5md7siz5qb.fsf@jtc.redbacknetworks.com>
References: <199911090706.CAA13120@zwingli.cygnus.com> <199911102246.RAA01846@mescaline.gnu.org> <npr9hi321d.fsf@zwingli.cygnus.com> <199911231303.IAA01523@mescaline.gnu.org> <npr9hg2a9t.fsf@zwingli.cygnus.com> <199911251715.MAA09225@mescaline.gnu.org> <npzovvc04o.fsf@zwingli.cygnus.com> <199912010821.DAA27130@mescaline.gnu.org> <npogca9tb8.fsf@zwingli.cygnus.com> <3845AB0E.3795D99E@ozemail.com.au> <5md7sql00o.fsf@jtc.redbacknetworks.com> <3845F45A.38EA29CF@ozemail.com.au> <384685A7.15184EB1@haulpak.com>
X-SW-Source: 1999-q4/msg00469.html
Content-length: 2083
>>>>> "William" == William Gatliff <gatliff@haulpak.com> writes:
William> If efficiency/throughput is a problem, then go to ethernet.
William> At 10/100Mbps, even the overhead of ASCII isn't a problem for
William> most targets I can think of.
Yet the protocol should be as efficent as possible. For many targets,
ethernet and a TCP/IP stack is a heavyweight requirement. I looked at
cleanly separating the layers in remote.c so I could use UDP some time
ago. About the same time, the mini-telnet stuff came in which assumes
a stream transport. Bleh.
Steven> I think there should be a general timing basis to the entire
Steven> protocol to tie up some potential communications/
Steven> implementation problems.
William> The RSP's lack of timing requirements is an asset, as far as I'm
William> concerned. See below.
Although Steven mentioned several alternatives of computing timeout
values from bit rate, message size, etc.; I believe that those are
secondary to his point that the protocol should identify that time-
outs are necessary to guarantee a reliable. Once they are identified,
the lengths of those timeouts can be implemented by GDB variables or
manifest constants in stub code, etc. But without them, I think that
we'll continue to have weaknesses in both.
Steven> Character Escaping: The mechanism of Escaping the characters is not
Steven> defined. Further it is only defined as used by write mem binary.
William> That's because this is the only place where it is needed,
William> AFAIK.
It's the only place where it's used now. But I wouldn't go so far as
saying that it's the only place where it's needed. Perhaps even more
useful than binary memory write is binary register write. Registers
are written quite often while stepping through a program.
Likewise, it would be useful to have a binary memory read and binary
register read. IMO, using the same escaping mechanisms for all such
commands would be good thing. To do so, I'd put it at the data link
layer instead of inside each command.
--jtc
--
J.T. Conklin
RedBack Networks
From jtc@redback.com Tue Dec 07 15:49:00 1999
From: jtc@redback.com (J.T. Conklin)
To: Andrew Cagney <ac131313@cygnus.com>
Cc: Steven Johnson <sbjohnson@ozemail.com.au>, gdb@sourceware.cygnus.com
Subject: Re: Standard GDB Remote Protocol
Date: Tue, 07 Dec 1999 15:49:00 -0000
Message-id: <5m9036z518.fsf@jtc.redbacknetworks.com>
References: <199911090706.CAA13120@zwingli.cygnus.com> <199911102246.RAA01846@mescaline.gnu.org> <npr9hi321d.fsf@zwingli.cygnus.com> <199911231303.IAA01523@mescaline.gnu.org> <npr9hg2a9t.fsf@zwingli.cygnus.com> <199911251715.MAA09225@mescaline.gnu.org> <38478423.6ACE7BF8@cygnus.com>
X-SW-Source: 1999-q4/msg00470.html
Content-length: 1301
>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
Andrew> How GDB behaves should be clarified. However, any definition should
Andrew> avoid refering to absolute times and instead refer the user back to a
Andrew> number of knobs that can be tweeked from the GDB command line.
Steven is/was examining the protocol specification without the GDB
and stub sources to avoid becoming biased by exposure. In addition,
I recommend that, at least at the present time, this also be true of
GDB's variables.
If Steven is willing to carry this a bit farther, I'd like to see the
protocol defined in terms of 'variables' which can be later mapped to
GDB's variables. Or in the case where GDB does not have such a user
configurable varible, a concious decision can be made whether to add
one or continue using whatever constant is in the source.
For example, this thread has me thinking that there are actually two
separate timeouts in the protocol. The timeout from when a packet is
sent and it is ACK/NAKed. And a timeout from when a command is sent
and it's response is received. At the present time, 'remotetimeout'
is used for both purposes. But it's reasonable to set the first to a
short value and the latter to something much larger.
--jtc
--
J.T. Conklin
RedBack Networks
From ac131313@cygnus.com Tue Dec 07 16:08:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: jtc@redback.com
Cc: pschen@puma.cs.nthu.edu.tw, gdb@sourceware.cygnus.com
Subject: Re: Exist a 68k simulator?
Date: Tue, 07 Dec 1999 16:08:00 -0000
Message-id: <384DA0FF.86D558DF@cygnus.com>
References: <NDBBLKOACKKKFPINNIPEOEKGCAAA.pschen@puma.cs.nthu.edu.tw> <5mwvqqzh1s.fsf@jtc.redbacknetworks.com>
X-SW-Source: 1999-q4/msg00471.html
Content-length: 376
"J.T. Conklin" wrote:
> > Where can I find a 68k simulator? ( want to put in /sim directory)
>
> Isn't there 68k simulator used in the PalmPilot and that coin-op video
> game emulator? Do the licences for those allow for inclusion within
> GDB?
No one is exactly clear on that one. If the answer had been yes, it
would have been integrated long ago :-)
enjoy,
Andrew
From jsm@cygnus.com Tue Dec 07 16:17:00 1999
From: Jason Molenda <jsm@cygnus.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: jtc@redback.com, pschen@puma.cs.nthu.edu.tw, gdb@sourceware.cygnus.com
Subject: Re: Exist a 68k simulator?
Date: Tue, 07 Dec 1999 16:17:00 -0000
Message-id: <19991207161726.B20332@cygnus.com>
References: <NDBBLKOACKKKFPINNIPEOEKGCAAA.pschen@puma.cs.nthu.edu.tw> <5mwvqqzh1s.fsf@jtc.redbacknetworks.com> <384DA0FF.86D558DF@cygnus.com>
X-SW-Source: 1999-q4/msg00472.html
Content-length: 1056
On Wed, Dec 08, 1999 at 11:06:23AM +1100, Andrew Cagney wrote:
> "J.T. Conklin" wrote:
>
> > > Where can I find a 68k simulator? ( want to put in /sim directory)
> >
> > Isn't there 68k simulator used in the PalmPilot and that coin-op video
> > game emulator? Do the licences for those allow for inclusion within
> > GDB?
>
> No one is exactly clear on that one. If the answer had been yes, it
> would have been integrated long ago :-)
I'll repeat the plug for the Unix Amiga Emulator projects'
68000/68020/68881 simulator. http://www.freiburg.linux.de/~uae/
I talked to the author/maintainer, Bernd Schmidt, about using it in GDB
a while ago. He expect no problems. It is GPL'ed. It is not the most
complete 68k simulator in the world, but he expected that it would
handle gcc-generated code OK. It has been appropriated by several
other projects as a generic CPU simulator in the past.
I don't have time to pursue this any further right now, but that looks
like a very good avenue to pursue if someone wanted to pull in a 68k
simulator.
J
From ac131313@cygnus.com Tue Dec 07 16:32:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: jtc@redback.com
Cc: Steven Johnson <sbjohnson@ozemail.com.au>, gdb@sourceware.cygnus.com
Subject: Re: Standard GDB Remote Protocol
Date: Tue, 07 Dec 1999 16:32:00 -0000
Message-id: <384DA6B9.339ED90D@cygnus.com>
References: <199911090706.CAA13120@zwingli.cygnus.com> <199911102246.RAA01846@mescaline.gnu.org> <npr9hi321d.fsf@zwingli.cygnus.com> <199911231303.IAA01523@mescaline.gnu.org> <npr9hg2a9t.fsf@zwingli.cygnus.com> <199911251715.MAA09225@mescaline.gnu.org>
X-SW-Source: 1999-q4/msg00473.html
Content-length: 1464
"J.T. Conklin" wrote:
>
> >>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
> Andrew> How GDB behaves should be clarified. However, any definition should
> Andrew> avoid refering to absolute times and instead refer the user back to a
> Andrew> number of knobs that can be tweeked from the GDB command line.
>
> Steven is/was examining the protocol specification without the GDB
> and stub sources to avoid becoming biased by exposure. In addition,
> I recommend that, at least at the present time, this also be true of
> GDB's variables.
>
> If Steven is willing to carry this a bit farther, I'd like to see the
> protocol defined in terms of 'variables' which can be later mapped to
> GDB's variables. Or in the case where GDB does not have such a user
> configurable varible, a concious decision can be made whether to add
> one or continue using whatever constant is in the source.
That would be bliss.
> For example, this thread has me thinking that there are actually two
> separate timeouts in the protocol. The timeout from when a packet is
> sent and it is ACK/NAKed. And a timeout from when a command is sent
> and it's response is received. At the present time, 'remotetimeout'
> is used for both purposes. But it's reasonable to set the first to a
> short value and the latter to something much larger.
There is also (as noted earlier) the time between each character that
arrives. GDB uses the same timeout for that.
Andrew
From ac131313@cygnus.com Tue Dec 07 17:03:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: jtc@redback.com
Cc: Steven Johnson <sbjohnson@ozemail.com.au>, gdb@sourceware.cygnus.com
Subject: Re: Standard GDB Remote Protocol
Date: Tue, 07 Dec 1999 17:03:00 -0000
Message-id: <384DAE26.241BCE2B@cygnus.com>
References: <199911090706.CAA13120@zwingli.cygnus.com> <199911102246.RAA01846@mescaline.gnu.org> <npr9hi321d.fsf@zwingli.cygnus.com> <199911231303.IAA01523@mescaline.gnu.org> <npr9hg2a9t.fsf@zwingli.cygnus.com> <199911251715.MAA09225@mescaline.gnu.org>
X-SW-Source: 1999-q4/msg00474.html
Content-length: 2366
"J.T. Conklin" wrote:
>
> Steven> 8/7 Bit protocol.
> Steven> With the documentation of RAW Binary transfers, the protocol moves from
> Steven> being a strictly 7 bit affair into being a 8 bit capable protocol. If
> Steven> this is so, then shouldn't all the restrictions that are placed from the
> Steven> 7 bit protocol days be lifted to take advantage of the capabilities of
> Steven> an 8 bit message stream. (RLE limitations, for example). Would anyone
> Steven> seriously be using a computer that had a 7 bit limitation anymore
> Steven> anyway? (At least a computer that would run GDB with remote debugging).
>
> I'm more concerned with the other side than the GDB side. I can
> imagine a target that could only reasonably support a 7 bit channel.
Yes, it's optional for that reason (and yes, the spec should clarify
that :-)
> Steven> Thoughts on consistency and future growth:
> Steven> Apply RLE as a feature of All messages. (Including binary messages, as
> Steven> these can probably benefit significantly from it).
>
> Steven> Apply the Binary Escaping mechanism as a feature of the packet that is
> Steven> performed on all messages prior to transmission and immediately after
> Steven> reception. Define an exhaustive set of "Characters to be escaped".
>
> Steven> Introduce message timing constraints.
> Steven> Properly define sequence-id and allow it to be used from GDB to make
> Steven> communications secure and reliable.
>
> These are all great, but I'm not sure how much can been within the
> confines of the existing protocol.
As a vague suggestion of a ``five year'' gdb-protocol plan:
v2.0: Formalize the lower layers (transport, ...?)
(Where's my AST networks book :-) and address
issues such as reliability.
The command set would remain the same - warts
and all.
v3.0: Look at the actual gdb command set
If the two can be separated then, there is some hope of being able to
move forward. As an incentive, the getpkt() and putpkt() functions and
several chunks of remote.c need a further rewrite any way. They should
to be inverted so that they are based on an event model. Clearly
separating the layers would help this.
The alternative, as always, is to start again from scratch.
Andrew
(As for the mini-telnet, if someone would like to propose a decent
telnet extenstion to the protocol then, I'm all ears)
From shebs@cygnus.com Tue Dec 07 17:41:00 1999
From: Stan Shebs <shebs@cygnus.com>
To: jsm@cygnus.com
Cc: cagney@cygnus.com, jtc@redback.com, pschen@puma.cs.nthu.edu.tw, gdb@sourceware.cygnus.com
Subject: Re: Exist a 68k simulator?
Date: Tue, 07 Dec 1999 17:41:00 -0000
Message-id: <199912080138.RAA27224@andros.cygnus.com>
References: <19991207161726.B20332@cygnus.com>
X-SW-Source: 1999-q4/msg00475.html
Content-length: 962
Date: Tue, 7 Dec 1999 16:17:26 -0800
From: Jason Molenda <jsm@cygnus.com>
I'll repeat the plug for the Unix Amiga Emulator projects'
68000/68020/68881 simulator. http://www.freiburg.linux.de/~uae/
I talked to the author/maintainer, Bernd Schmidt, about using it in GDB
a while ago. He expect no problems. It is GPL'ed. It is not the most
complete 68k simulator in the world, but he expected that it would
handle gcc-generated code OK. It has been appropriated by several
other projects as a generic CPU simulator in the past.
I don't have time to pursue this any further right now, but that looks
like a very good avenue to pursue if someone wanted to pull in a 68k
simulator.
Indeed, this would be a good project for someone that wanted to get
their feet wet in embedded GDB hacking. The technical parts are not
too hard, you don't need special hardware, and people will appreciate
the contribution.
Stan
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: ST(i) and MMj
[not found] ` <npk8msaqoo.fsf@zwingli.cygnus.com>
@ 1999-12-08 1:46 ` Eli Zaretskii
[not found] ` <npogc1afwn.fsf@zwingli.cygnus.com>
0 siblings, 1 reply; 8+ messages in thread
From: Eli Zaretskii @ 1999-12-08 1:46 UTC (permalink / raw)
To: jimb; +Cc: ac131313, gdb
> > * Change functions that read and write registers from/to memory to
> > handle the MMX registers specially by looking at the appropriate
> > ST(i) register instead.
>
> Which functions would these be, exactly?
>
> On the i386, both variable references and direct register references
> (like $eax) go through (via a torturous chain of calls)
> read_register_gen, which just reaches directly into the register file.
Okay, let's look at read_register_gen (I removed the irrelevant
clutter):
void
read_register_gen (regno, myaddr)
int regno;
char *myaddr;
{
if (!register_valid[regno])
target_fetch_registers (regno);
memcpy (myaddr, ®isters[REGISTER_BYTE (regno)],
REGISTER_RAW_SIZE (regno));
}
This can be changed like this:
1) Define REGISTER_RAW_SIZE to be 8 for MMX registers, and define
REGISTER_BYTE so that for MMX registers it goes to the data of
the according ST(i) register using the current TOS.
2) target_fetch_registers then will actually bring the value of the
appropriate ST(i) register when passed a regno of an MMX
register.
> I think I'd need to see a very specific explanation of how to do this,
> showing which functions to change, etc. Talking about it at a higher
> level is just getting confusing.
You are right. All functions in findvar.c that deal with registers
will have to be inspected, but just by looking at these functions, it
seems like a smart enough definition of REGISTER_* macros will do most
of the work. We might also need to update register_valid[] for an MMX
register together with its corresponding ST(i) register, though; this
might require to introduce a target-dependent function to update
register_valid[] when a given register REGNO is fetched (but code that
reads register_valid[] can be left intact).
If it will help, I can try to make these changes, once the MMX support
for x86 is in place.
From jimb@cygnus.com Wed Dec 08 02:25:00 1999
From: Jim Blandy <jimb@cygnus.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: ac131313@cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: ST(i) and MMj
Date: Wed, 08 Dec 1999 02:25:00 -0000
Message-id: <npogc1afwn.fsf@zwingli.cygnus.com>
References: <199911090706.CAA13120@zwingli.cygnus.com> <199911102246.RAA01846@mescaline.gnu.org> <npr9hi321d.fsf@zwingli.cygnus.com> <199911231303.IAA01523@mescaline.gnu.org> <npr9hg2a9t.fsf@zwingli.cygnus.com> <199911251715.MAA09225@mescaline.gnu.org> <npzovvc04o.fsf@zwingli.cygnus.com> <199912010821.DAA27130@mescaline.gnu.org> <npogca9tb8.fsf@zwingli.cygnus.com> <38478987.EECEEBF@cygnus.com> <199912061134.GAA16617@mescaline.gnu.org> <npk8msaqoo.fsf@zwingli.cygnus.com> <199912080946.EAA05898@mescaline.gnu.org>
X-SW-Source: 1999-q4/msg00477.html
Content-length: 2381
> Okay, let's look at read_register_gen (I removed the irrelevant
> clutter):
>
> void
> read_register_gen (regno, myaddr)
> int regno;
> char *myaddr;
> {
> if (!register_valid[regno])
> target_fetch_registers (regno);
> memcpy (myaddr, ®isters[REGISTER_BYTE (regno)],
> REGISTER_RAW_SIZE (regno));
> }
>
> This can be changed like this:
>
> 1) Define REGISTER_RAW_SIZE to be 8 for MMX registers, and define
> REGISTER_BYTE so that for MMX registers it goes to the data of
> the according ST(i) register using the current TOS.
>
> 2) target_fetch_registers then will actually bring the value of the
> appropriate ST(i) register when passed a regno of an MMX
> register.
I thought we had posited that the MMX registers, when stored in
memory, have zero length --- i.e., REGISTER_RAW_SIZE (MM0_REGNO) == 0
--- to avoid overlap problems in loops.
> > I think I'd need to see a very specific explanation of how to do this,
> > showing which functions to change, etc. Talking about it at a higher
> > level is just getting confusing.
>
> You are right. All functions in findvar.c that deal with registers
> will have to be inspected, but just by looking at these functions, it
> seems like a smart enough definition of REGISTER_* macros will do most
> of the work. We might also need to update register_valid[] for an MMX
> register together with its corresponding ST(i) register, though; this
> might require to introduce a target-dependent function to update
> register_valid[] when a given register REGNO is fetched (but code that
> reads register_valid[] can be left intact).
>
> If it will help, I can try to make these changes, once the MMX support
> for x86 is in place.
I'm sure we could make something work. What concerns me is that it be
reasonable enough that people who are not familiar with the x86 won't
write code that breaks it. Having REGISTER_RAW_SIZE be zero is on the
edge, and now we're positing further things to maintain register_valid
...
I have another proposal in mind which is more work, and more invasive,
but is more generally useful. It would allow us to solve this
problem, and implement base-relative FP register numbering (as
discussed long ago on the EGCS list), and deal with some others I
think I remember hearing about over the years. I'll describe it here
soon.
From jtc@redback.com Wed Dec 08 15:54:00 1999
From: jtc@redback.com (J.T. Conklin)
To: Andrew Cagney <ac131313@cygnus.com>
Cc: Steven Johnson <sbjohnson@ozemail.com.au>, gdb@sourceware.cygnus.com
Subject: Re: Standard GDB Remote Protocol
Date: Wed, 08 Dec 1999 15:54:00 -0000
Message-id: <5mbt81ugxx.fsf@jtc.redbacknetworks.com>
References: <199911090706.CAA13120@zwingli.cygnus.com> <199911102246.RAA01846@mescaline.gnu.org> <npr9hi321d.fsf@zwingli.cygnus.com> <199911231303.IAA01523@mescaline.gnu.org> <npr9hg2a9t.fsf@zwingli.cygnus.com> <199911251715.MAA09225@mescaline.gnu.org> <384DAE26.241BCE2B@cygnus.com>
X-SW-Source: 1999-q4/msg00478.html
Content-length: 3061
>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
jtc>
jtc> These are all great, but I'm not sure how much can been within the
jtc> confines of the existing protocol.
Andrew> As a vague suggestion of a ``five year'' gdb-protocol plan:
Andrew>
Andrew> v2.0: Formalize the lower layers (transport, ...?)
Andrew> (Where's my AST networks book :-) and address
Andrew> issues such as reliability.
Andrew>
Andrew> The command set would remain the same - warts
Andrew> and all.
Andrew>
Andrew> v3.0: Look at the actual gdb command set
Mine has been at my side for the last week or so, in the vain hope
that I'd have a few minutes to spare to participate in this thread.
I've been chastised a few times in the last week about having the
'obsolete' second edition. :-)
I think that formalizing the existing packet transport is essential.
To move forward, we must first know where we stand. Even if we are
not able fix all of the problems (because doing so would require
incompatible changes to the framing mechanism, etc.), we should be
able to come up with a list of best or recommended practices and
ensure that remote.c and the sample stubs adhere to them.
Andrew> If the two can be separated then, there is some hope of being
Andrew> able to move forward.
If the two layers can can be separated, I see no technical reason that
changes to the command layer be delayed until changes to the transport
layer are completed. In an ideal world, work on both could progress
in parallel. However, I suspect that the people interested in
improving the transport layer are the very same people interested in
improving the command layer. Thus sequencing the projects is probably
the right thing to do.
Andrew> The alternative, as always, is to start again from scratch.
I've been convinced that a new protocol is needed for the last year or
so. At the same time, I am glad I didn't start designing/implementing
one at that time. I believe the likely result of such an effort would
have been unsuccessful.
During the last year, besides complaining about the existing RDP :-),
I've been able to put a lot more thought into the limitations of the
RDP and how I'd address them. I feel I'm in a much better position
to do it right now than I was then.
Andrew> (As for the mini-telnet, if someone would like to propose a
Andrew> decent telnet extenstion to the protocol then, I'm all ears)
If we change the lower levels, this becomes easy. Each packet would
have a 'protocol' field which would indicate which upper level stack
would handle the packet. One value would indicate be a GDB command/
response protocl. Another would be a Link Control Protocol used to
establish/negotiate link layer options (8 vs. 7 bit, hex vs. base64
encoding, RLE compression, etc.).
To replace minitelnet, a lightweight 'protocol' to transfer console
i/o to and from the target. With a bit more effort, a virtual i/o
scheme could be invented so the target could use the host's file-
system and devices.
--jtc
--
J.T. Conklin
RedBack Networks
From ac131313@cygnus.com Wed Dec 08 20:56:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: jtc@redback.com
Cc: Steven Johnson <sbjohnson@ozemail.com.au>, gdb@sourceware.cygnus.com
Subject: Re: Standard GDB Remote Protocol
Date: Wed, 08 Dec 1999 20:56:00 -0000
Message-id: <384F3633.B395BFB1@cygnus.com>
References: <199911090706.CAA13120@zwingli.cygnus.com> <199911102246.RAA01846@mescaline.gnu.org> <npr9hi321d.fsf@zwingli.cygnus.com> <199911231303.IAA01523@mescaline.gnu.org> <npr9hg2a9t.fsf@zwingli.cygnus.com> <199911251715.MAA09225@mescaline.gnu.org>
X-SW-Source: 1999-q4/msg00479.html
Content-length: 1604
"J.T. Conklin" wrote:
> Andrew> If the two can be separated then, there is some hope of being
> Andrew> able to move forward.
>
> If the two layers can can be separated, I see no technical reason that
> changes to the command layer be delayed until changes to the transport
> layer are completed. In an ideal world, work on both could progress
> in parallel. However, I suspect that the people interested in
> improving the transport layer are the very same people interested in
> improving the command layer. Thus sequencing the projects is probably
> the right thing to do.
That is a very good point. There is definitly room for overlap. Once
the hair between the commands and the transport are separated, things
can move more freely.
> Andrew> (As for the mini-telnet, if someone would like to propose a
> Andrew> decent telnet extenstion to the protocol then, I'm all ears)
>
> If we change the lower levels, this becomes easy. Each packet would
> have a 'protocol' field which would indicate which upper level stack
> would handle the packet. One value would indicate be a GDB command/
> response protocl. Another would be a Link Control Protocol used to
> establish/negotiate link layer options (8 vs. 7 bit, hex vs. base64
> encoding, RLE compression, etc.).
This is starting to sound like IP:-) Just as long as it isn't as heavy
:-)
> To replace minitelnet, a lightweight 'protocol' to transfer console
> i/o to and from the target. With a bit more effort, a virtual i/o
> scheme could be invented so the target could use the host's file-
> system and devices.
Agreed.
Andrew
From ac131313@cygnus.com Thu Dec 09 00:11:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: jtc@redback.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: memory region attributes
Date: Thu, 09 Dec 1999 00:11:00 -0000
Message-id: <384F63D7.295BD224@cygnus.com>
References: <5m3dux68hc.fsf@jtc.redbacknetworks.com>
X-SW-Source: 1999-q4/msg00480.html
Content-length: 1839
"J.T. Conklin" wrote:
Sorry, this just sat in my in tray :-(
> Synopsis:
> (gdb) mem <start address> <end_address> [attribute ...]
>
> Attributes:
> rw - memory is read/write (default)
> ro - memory is read only, GDB will refuse to issue a write
> command.
> wo - memory is write only, GDB will refuse to issue a read
> command.
>
> 8,16,32 - access memory in X sized operations
>
> hwbreak - GDB internal breakpoints use hw breakpoints
> swbreak - GDB internal breakpoints use sw breakpoints (default)
>
> cache - enable host-side caching
> nocache - disable host-side caching (default)
>
> Examples:
> (gdb) mem &start &etext ro cache
> (gdb) mem &uart_base &uart_base + 0x0f 8
J.T. as a representation of the actual memory, you may want to look at
what the simulators are using (sim/common/sim-core.c,
sim/common/sim-memopt.c). The code started out with a simile model as
you've described but ended up with a slightly more complex
representation of target memory. It is very much a reflection of the
tricks that hardware engineeers like to play with address decode lines
:-)
Briefly:
o The regions can be layered.
That way it is clear what happens
if two regions overlap.
This reflects memory with ``holes''
o Memory regions can be shaddowed/aliases
Region 0x100..0x200 also at 0x1100..0x1200
This reflects how some address lines
are not decoded.
o Similarly, memory can be repeated
across a region. The same block
appearing at 0x0..0x10, 0x10..0x20,
and so on for an entire 1mb.
Hmm, perhaphs, instead of something like this where the user specifies
constants mem should take an equation that returns the relevant
attributes. That way the user can built up an arbitrary set of rules
about what memory can be accessed.
Andrew
From eliz@gnu.org Thu Dec 09 02:29:00 1999
From: Eli Zaretskii <eliz@gnu.org>
To: jimb@cygnus.com
Cc: ac131313@cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: ST(i) and MMj
Date: Thu, 09 Dec 1999 02:29:00 -0000
Message-id: <199912091029.FAA13387@mescaline.gnu.org>
References: <199911090706.CAA13120@zwingli.cygnus.com> <199911102246.RAA01846@mescaline.gnu.org> <npr9hi321d.fsf@zwingli.cygnus.com> <199911231303.IAA01523@mescaline.gnu.org> <npr9hg2a9t.fsf@zwingli.cygnus.com> <199911251715.MAA09225@mescaline.gnu.org> <npzovvc04o.fsf@zwingli.cygnus.com> <199912010821.DAA27130@mescaline.gnu.org> <npogca9tb8.fsf@zwingli.cygnus.com> <38478987.EECEEBF@cygnus.com> <199912061134.GAA16617@mescaline.gnu.org> <npk8msaqoo.fsf@zwingli.cygnus.com> <199912080946.EAA05898@mescaline.gnu.org> <npogc1afwn.fsf@zwingli.cygnus.com>
X-SW-Source: 1999-q4/msg00481.html
Content-length: 1006
> > 1) Define REGISTER_RAW_SIZE to be 8 for MMX registers, and define
> > REGISTER_BYTE so that for MMX registers it goes to the data of
> > the according ST(i) register using the current TOS.
> >
> > 2) target_fetch_registers then will actually bring the value of the
> > appropriate ST(i) register when passed a regno of an MMX
> > register.
>
> I thought we had posited that the MMX registers, when stored in
> memory, have zero length --- i.e., REGISTER_RAW_SIZE (MM0_REGNO) == 0
> --- to avoid overlap problems in loops.
The above still avoids overlap, by keeping only a single copy of each
FPU register in the register file. However, the zero-size definition
isn't useful when you want to read the value of an MMX register from
the register file. So I changed my mind ;-).
> What concerns me is that it be reasonable enough that people who are
> not familiar with the x86 won't write code that breaks it.
Hiding the complexity behind REGISTER_BYTE should prevent this.
From qqi@world.std.com Thu Dec 09 08:32:00 1999
From: Quality Quorum <qqi@world.std.com>
To: gdb@sourceware.cygnus.com
Subject: licensing issues
Date: Thu, 09 Dec 1999 08:32:00 -0000
Message-id: <Pine.SGI.3.95.991209111558.13465A-100000@world.std.com>
X-SW-Source: 1999-q4/msg00482.html
Content-length: 1037
Hi,
I am developing replacement/enchancement for gdbserver. The major
difference is that it will allow to debug not only process on
the remote machine, but it also allows to debug an embedded system
attached to the remote machine, plus it has support for bigger
amount of recent quirks.
I have a question related to GPL. I posted it earlier and I got no
response. I am posting it again in a hope that ones in the know,
would respond. I would like to allow a possibility to attach
debuggers with proprietary interfaces (e.g macraigor wiggler).
I would like to publish my work under GPL, however, it is unclear
to me whether my intention to allow proprietary stuff (in the form
of shared libs) in is in line with GPL. In my view it is: I put
.h file defining interface into public domain and there is no
need for anybody to use or link any other part of GPL'ed code in
proprietary library: there are only three callback functions, which
are passed as pointers through the API, and no data sharing.
Thanks,
Aleksey
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: ST(i) and MMj
[not found] ` <199912091029.FAA13387@mescaline.gnu.org>
@ 1999-12-10 5:51 ` Andrew Cagney
0 siblings, 0 replies; 8+ messages in thread
From: Andrew Cagney @ 1999-12-10 5:51 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: jimb, gdb
Eli Zaretskii wrote:
>
> > > 1) Define REGISTER_RAW_SIZE to be 8 for MMX registers, and define
> > > REGISTER_BYTE so that for MMX registers it goes to the data of
> > > the according ST(i) register using the current TOS.
> > >
> > > 2) target_fetch_registers then will actually bring the value of the
> > > appropriate ST(i) register when passed a regno of an MMX
> > > register.
> >
> > I thought we had posited that the MMX registers, when stored in
> > memory, have zero length --- i.e., REGISTER_RAW_SIZE (MM0_REGNO) == 0
> > --- to avoid overlap problems in loops.
>
> The above still avoids overlap, by keeping only a single copy of each
> FPU register in the register file. However, the zero-size definition
> isn't useful when you want to read the value of an MMX register from
> the register file. So I changed my mind ;-).
>
> > What concerns me is that it be reasonable enough that people who are
> > not familiar with the x86 won't write code that breaks it.
>
> Hiding the complexity behind REGISTER_BYTE should prevent this.
Only to confuse the poor person that has to fix a bug in REGISTER_BYTE
:-)
I think Jim's point is important. The current semantics of this macro
is fairly straight forward - return the offset of the byte in a raw
buffer. Compare that to some of the other target macro's such as
REGISTER_NAME / REGISTER_NAMES.
There's an oportunity here to eliminate a problem with GDB for all
targets.
enjoy,
Andrew
From jtc@redback.com Fri Dec 10 12:42:00 1999
From: jtc@redback.com (J.T. Conklin)
To: Andrew Cagney <ac131313@cygnus.com>
Cc: Steven Johnson <sbjohnson@ozemail.com.au>, gdb@sourceware.cygnus.com
Subject: Re: Standard GDB Remote Protocol
Date: Fri, 10 Dec 1999 12:42:00 -0000
Message-id: <5mpuwetto7.fsf@jtc.redbacknetworks.com>
References: <199911090706.CAA13120@zwingli.cygnus.com> <199911102246.RAA01846@mescaline.gnu.org> <npr9hi321d.fsf@zwingli.cygnus.com> <199911231303.IAA01523@mescaline.gnu.org> <npr9hg2a9t.fsf@zwingli.cygnus.com> <199911251715.MAA09225@mescaline.gnu.org> <384F3633.B395BFB1@cygnus.com>
X-SW-Source: 1999-q4/msg00487.html
Content-length: 2116
>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
>> If we change the lower levels, this becomes easy. Each packet
>> would have a 'protocol' field which would indicate which upper
>> level stack would handle the packet. One value would indicate be a
>> GDB command/ response protocl. Another would be a Link Control
>> Protocol used to establish/negotiate link layer options (8 vs. 7
>> bit, hex vs. base64 encoding, RLE compression, etc.).
Andrew> This is starting to sound like IP:-) Just as long as it isn't
Andrew> as heavy :-)
I was thinking more along the lines of something between SL/IP and
PPP.
WRS uses SL/IP with a shim IP and UDP layer, on top of which they run
their SunRPC based protocol. It's not a full stack by any means, but
it's enough of one that you can connect a target to a terminal server
(or configure your host to run SL/IP) and connect to it over the
network. The disadvantage of this is that it adds substantial packet
overhead (IP and UDP headers) and target code to implement the shim
network layers.
SL/IP by itself doesn't buy us much, since it's really just a packet
framing mechanism. In many ways, it is inferior to the existing RDP
framing. For example, packet integrity (checksums) is left to upper
network layers.
PPP is more complicated. Although it should be possible to have RDP
as one of PPP's encapsualted protocols (like IP, IPX, etc.), I don't
think we'd actually want to do so. I suspect that GDB would have to
implement a host side stack as well, even on hosts that support PPP,
in order for GDB to tunnel RDP. Of course, the target would need a
PPP stack as well.
Even without those problems, It's not clear that PPP is appropriate.
PPP leaves reliable transport to the upper layers; and that's one of
the problems we're having with the existing RDP.
So, what we want is something with the simplicity and efficiency of
SL/IP, with link layer configuration/negotiation and multi protocol
support of PPP, plus a reliable transport shared by all protcols (RDP
commands, virtual I/O, etc.)
--jtc
--
J.T. Conklin
RedBack Networks
From qqi@world.std.com Fri Dec 10 19:29:00 1999
From: Quality Quorum <qqi@world.std.com>
To: gdb@sourceware.cygnus.com
Subject: another bug in remote.c
Date: Fri, 10 Dec 1999 19:29:00 -0000
Message-id: <Pine.SGI.3.95.991210221737.22433A-100000@world.std.com>
X-SW-Source: 1999-q4/msg00488.html
Content-length: 555
Hi,
I got another bug. This time I do not know how to fix it.
It is possible to get into following sequence of of events:
gdb: $m4000ab70,c8#22 -- asks for 200 bytes of memory
stub: $<400 chars>#XX -- stub responds correctly, packet
length 404 bytes
gdb: Remote packet too long -- gdb unhappy
I suspect that PBUFSIZ should not be used to determine
max_buf_size in remote_read_bytes(). It seems like there are
more places where similar problem may occur.
Thanks,
Aleksey
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~1999-12-10 5:51 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <199911090706.CAA13120@zwingli.cygnus.com>
[not found] ` <199911102246.RAA01846@mescaline.gnu.org>
[not found] ` <npr9hi321d.fsf@zwingli.cygnus.com>
[not found] ` <199911231303.IAA01523@mescaline.gnu.org>
[not found] ` <npr9hg2a9t.fsf@zwingli.cygnus.com>
[not found] ` <199911251715.MAA09225@mescaline.gnu.org>
1999-11-30 10:20 ` none Jim Blandy
1999-12-01 0:21 ` ST(i) and MMj Eli Zaretskii
[not found] ` <npogca9tb8.fsf@zwingli.cygnus.com>
[not found] ` <3845AB0E.3795D99E@ozemail.com.au>
1999-12-01 15:43 ` Standard GDB Remote Protocol Quality Quorum
1999-12-01 15:53 ` Stan Shebs
[not found] ` <5md7sql00o.fsf@jtc.redbacknetworks.com>
[not found] ` <3845F45A.38EA29CF@ozemail.com.au>
[not found] ` <384685A7.15184EB1@haulpak.com>
[not found] ` <38470CC1.1B0E5C27@ozemail.com.au>
1999-12-03 5:41 ` Bill Gatliff
1999-12-07 14:13 ` J.T. Conklin
[not found] ` <38478987.EECEEBF@cygnus.com>
[not found] ` <199912061134.GAA16617@mescaline.gnu.org>
[not found] ` <npk8msaqoo.fsf@zwingli.cygnus.com>
1999-12-08 1:46 ` ST(i) and MMj Eli Zaretskii
[not found] ` <npogc1afwn.fsf@zwingli.cygnus.com>
[not found] ` <199912091029.FAA13387@mescaline.gnu.org>
1999-12-10 5:51 ` Andrew Cagney
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox