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

[greyham@research.canon.com.au (Graham Stoney)]

Graham Stoney wrote:
> I'm wondering if anyone has had any success using gdb from an Linux x86
> machine to debug an MPC8xx target via BDM using a Macraigor Raven OCDemon?

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