Re: BDM/OCD with Macraigor Raven on MPC8xx from x86

Graham Stoney
1999-12-06T00:08:00Z

Steven Johnson writes:
> Can not be done.
>
> Macraigor will not release the specification to enable GDB to interface
> directly to their OCD Debuggers. The only support is through the
> Macraigor supplied DLL, and that only runs under windows. If you can get
> the specs for their devices then you can always write the interface from
> linux :).

Looks like the only viable GDB option with the Raven is under Cygwin then;
has anyone had success getting this to work? The gdb binary in B20 doesn't
appear to include the ocd target, which means configuring it myself...

Alternatively, is there a better option than Macraigor? I know we could wire
up our own BDM interface, but we have budget and I'd like to buy a commercial
one so we can focus on designing our target hardware.

Thanks,
Graham
From ac131313@cygnus.com Mon Dec 06 03:26:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: Quality Quorum <qqi@world.std.com>
Cc: gdb@sourceware.cygnus.com, Stan Shebs <shebs@cygnus.com>
Subject: Re: bugs in remote.c
Date: Mon, 06 Dec 1999 03:26:00 -0000
Message-id: <384B9CFD.38F32FD9@cygnus.com>
References: <Pine.SGI.3.95.991205140345.4355A-100000@world.std.com>
X-SW-Source: 1999-q4/msg00451.html
Content-length: 1711

Quality Quorum wrote:
>
> Hi,
>
> It seems to me that minimal requirements to a stub should be:
>
> 1. Return empty on everything it does not understand.
> 2. Does not change its mind about understanding something while
> in the middle of operation. E.g. if it supports extended ops
> should also support restart.
> 3. Return 'ENN' if (a) fatal error occured or (b) memory error
> occured.
>
> It seems to me that it is an absolute minimum set of requirements,
> which will allow to complex stuff like queries to work properly.

(Have a read of what the protocol has to say about the query packet and
some of its its features :-)

> It seems to me that people with uncompliant stubs should keep
> using gdb-4.18 or earlier, which are pretty decent debuggers
> anyway. Also, it seems like really simple thing to add
> something like 'old-remote' target which will lack new and shining
> stuff (e.g. extended ops, single register assignments and queries) but
> will be more tolerant towards old screwed up stubs.

Remember, the existing stubs can't be described as non-compliant as,
when they were written, there was no spec to comply to :-).

I don't think it is realistic to be talking about deserting people with
less than a year old stub/gdb. If there is going to be a cleanup of the
remote protocol then a way will need to be found that doesn't disrupt
the existing user base. Per other discussions a remote-protocol v2 with
some of the existing protocol lint removed may be a solution. The
old-remote might be useful. (However, at present there is async and
extended-async while we transition the async code. I'd rather have only
one protocol variant running at a time).

enjoy,
Andrew
From eliz@gnu.org Mon Dec 06 03:34:00 1999
From: Eli Zaretskii <eliz@gnu.org>
To: ac131313@cygnus.com
Cc: jimb@cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: ST(i) and MMj
Date: Mon, 06 Dec 1999 03:34:00 -0000
Message-id: <199912061134.GAA16617@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>
X-SW-Source: 1999-q4/msg00452.html
Content-length: 1133

> > Grep the sources for NUM_REGS, and look for loops that traverse the
> > register set. Prove to yourself that none of these loops will break
> > if register X aliases register Y. Persuade yourself that nobody in
> > the future, innocent of the x86's sins, will write such a loop.
> >
> > I tried, but I couldn't manage it. :)
>
> I agree with Jim. The way GDB currently resolves register names/numbers
> ``freaks me out''.

I don't know, it might be that I'm missing some crucial aspect of
this, but I did grep the sources for NUM_REGS, and didn't see anything
that cannot be taken care of by a combination of two simple tricks:

* Make macros like REGISTER_BYTES, REGISTER_BYTE, REGISTER_RAW_SIZE,
etc. behave as if the MMX registers, when stored in memory, have
zero length;

* 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.

Both of these aspects are either target-specific or rely heavily on
target-specific subroutines, so it shouldn't be too hard to do it
without affecting other platforms.
From ac131313@cygnus.com Mon Dec 06 03:55:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: Quality Quorum <qqi@world.std.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: remote.c patch
Date: Mon, 06 Dec 1999 03:55:00 -0000
Message-id: <384BA3CB.6E5DD7BC@cygnus.com>
References: <Pine.SGI.3.95.991204145527.3680A-200000@world.std.com>
X-SW-Source: 1999-q4/msg00453.html
Content-length: 1431

Quality Quorum wrote:
>
> Hi,
>
> I got this patch attached, I made it against latest snapshot I have
> (gdb-19990913).
>
> Now a few related comments:
>
> 1. I used gdbserver to test remote target.
>
> a. It is not part of default compilation on my Linux RH5.2.
>
> b. It did not compile.
>
> c. It was quite painful to make it work. I can clean it up too, if
> necessary, howver, I do not have access to anything but Linux RH5.2
> and FreeBSD 3.2.
>

Thanks for this, it's going to take some time to look it over but yes,
some of the things are bugs. Not checking that a Z packet continues to
be supported, for instance, is definitly a bug.

Andrew

Just FYI,

> ***************
> *** 4385,4393 ****
> if (strcmp (buf, "OK") == 0)
> break;
> ! if (strlen (buf) == 3 && buf[0] == 'E'
> ! && isdigit (buf[1]) && isdigit (buf[2]))
> {
> error ("Protocol error with Rcmd");
> }
> for (p = buf; p[0] != '\0' && p[1] != '\0'; p += 2)
> {
> --- 4536,4545 ----
> if (strcmp (buf, "OK") == 0)
> break;
> !
> ! if (buf[0] == 'E')
> {
> error ("Protocol error with Rcmd");
> }
> +
> for (p = buf; p[0] != '\0' && p[1] != '\0'; p += 2)
> {
> ***************

A two hex-digit response with digit ``E'' is valid. That is why the code
had such a complicated check.

Andrew
From ac131313@cygnus.com Mon Dec 06 04:00:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: Re: remote.c patch
Date: Mon, 06 Dec 1999 04:00:00 -0000
Message-id: <384BA54B.A55B3E91@cygnus.com>
References: <Pine.SGI.3.95.991204145527.3680A-200000@world.std.com> <384BA3CB.6E5DD7BC@cygnus.com>
X-SW-Source: 1999-q4/msg00454.html
Content-length: 91

Andrew Cagney wrote:
...

Sorry, I should have send the response to gdb-patches.

Andrew
From qqi@world.std.com Mon Dec 06 07:36:00 1999
From: Quality Quorum <qqi@world.std.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: remote.c patch
Date: Mon, 06 Dec 1999 07:36:00 -0000
Message-id: <Pine.SGI.3.95.991206103517.8150D-100000@world.std.com>
References: <384BA3CB.6E5DD7BC@cygnus.com>
X-SW-Source: 1999-q4/msg00455.html
Content-length: 1009

On Mon, 6 Dec 1999, Andrew Cagney wrote:

> > ***************
> > *** 4385,4393 ****
> > if (strcmp (buf, "OK") == 0)
> > break;
> > ! if (strlen (buf) == 3 && buf[0] == 'E'
> > ! && isdigit (buf[1]) && isdigit (buf[2]))
> > {
> > error ("Protocol error with Rcmd");
> > }
> > for (p = buf; p[0] != '\0' && p[1] != '\0'; p += 2)
> > {
> > --- 4536,4545 ----
> > if (strcmp (buf, "OK") == 0)
> > break;
> > !
> > ! if (buf[0] == 'E')
> > {
> > error ("Protocol error with Rcmd");
> > }
> > +
> > for (p = buf; p[0] != '\0' && p[1] != '\0'; p += 2)
> > {
> > ***************
>
> A two hex-digit response with digit ``E'' is valid. That is why the code
> had such a complicated check.

Thanks, is it possible to get a pointer to where recent additions
are described ?

BTW, was it possible to pick up another character beside 'E' ? :)

>
> Andrew
>

Thanks,

Aleksey