From mboxrd@z Thu Jan 1 00:00:00 1970 From: greyham@research.canon.com.au (Graham Stoney) To: gdb@sourceware.cygnus.com Subject: Re: BDM/OCD with Macraigor Raven on MPC8xx from x86 Date: Mon, 06 Dec 1999 00:08:00 -0000 Message-id: <19991206080740.CB98CF4D0@elph.research.canon.com.au> References: <384B53DD.B65146C7@ozemail.com.au> X-SW-Source: 1999-q4/msg00450.html 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 To: Quality Quorum Cc: gdb@sourceware.cygnus.com, Stan Shebs Subject: Re: bugs in remote.c Date: Mon, 06 Dec 1999 03:26:00 -0000 Message-id: <384B9CFD.38F32FD9@cygnus.com> References: 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 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> <199911231303.IAA01523@mescaline.gnu.org> <199911251715.MAA09225@mescaline.gnu.org> <199912010821.DAA27130@mescaline.gnu.org> <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 To: Quality Quorum 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: 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 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: <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 To: Andrew Cagney Cc: gdb@sourceware.cygnus.com Subject: Re: remote.c patch Date: Mon, 06 Dec 1999 07:36:00 -0000 Message-id: 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