From mboxrd@z Thu Jan 1 00:00:00 1970 From: jtc@redback.com (J.T. Conklin) To: Andrew Cagney Cc: Ian Lance Taylor , gdb-patches@sourceware.cygnus.com Subject: Re: Patch to speed up remote protocol Date: Wed, 07 Jul 1999 15:39:00 -0000 Message-id: <5md7y42ii0.fsf@jtc.redbacknetworks.com> References: <19990702201648.32062.qmail@daffy.airs.com> <378338EC.C709D54@cygnus.com> X-SW-Source: 1999-q3/msg00012.html >>>>> "Andrew" == Andrew Cagney writes: Andrew> Attached is a patch that integrates your change into a general Andrew> cleanup of ``P'' packet support code. The patch adds the Andrew> commands: Andrew> Andrew> set stub-supports-P-packet {supported,unsupported,auto} Andrew> show stub-supports-P-packet Andrew> Andrew> so explicit examination/control is also possible. (I'm very Andrew> interested in suggestions for a better variable name). The Andrew> bulk of the code is also generic so that it can be re-used by Andrew> code detecting other optional packets. I'm not sure I like the idea of setting GDB's support of the P packet from the CLI. If it can be autonegotiated successfully (which my experience has shown to be true), there doesn't seem to be a need. I do agree that once a stub accepts 'P', it should be expected to always support it within that debugging session. As for names, it probably should have "remote" in the name to tie it to the other remote protocol variables. Perhaps: remote-stub-supports-P-packet remote-protocol-supports-P-packet remote-protocol-supports-register-set But that's only if there really is a need for this variable. We shouldn't add knobs just because we can. --jtc -- J.T. Conklin RedBack Networks >From ac131313@cygnus.com Wed Jul 07 17:53:00 1999 From: Andrew Cagney To: jtc@redback.com Cc: Ian Lance Taylor , gdb-patches@sourceware.cygnus.com Subject: Re: Patch to speed up remote protocol Date: Wed, 07 Jul 1999 17:53:00 -0000 Message-id: <3783F623.8A26DA77@cygnus.com> References: <19990702201648.32062.qmail@daffy.airs.com> <378338EC.C709D54@cygnus.com> <5md7y42ii0.fsf@jtc.redbacknetworks.com> X-SW-Source: 1999-q3/msg00013.html Content-length: 2424 "J.T. Conklin" wrote: > > >>>>> "Andrew" == Andrew Cagney writes: > Andrew> Attached is a patch that integrates your change into a general > Andrew> cleanup of ``P'' packet support code. The patch adds the > Andrew> commands: > Andrew> > Andrew> set stub-supports-P-packet {supported,unsupported,auto} > Andrew> show stub-supports-P-packet > Andrew> > Andrew> so explicit examination/control is also possible. (I'm very > Andrew> interested in suggestions for a better variable name). The > Andrew> bulk of the code is also generic so that it can be re-used by > Andrew> code detecting other optional packets. > > I'm not sure I like the idea of setting GDB's support of the P packet > from the CLI. If it can be autonegotiated successfully (which my > experience has shown to be true), there doesn't seem to be a need. I > do agree that once a stub accepts 'P', it should be expected to always > support it within that debugging session. FYI, auto-detect is the default. Below is a typical interaction: The initial ``set stub-supports-P-packet auto'' forces GDB back into its default state and make things interesting. (gdb) set stub-supports-P-packet auto (gdb) show stub-supports-P-packet stub-supports-P-packet is auto-detected, currently unknown (gdb) set $d1 = 2 Sending packet: $P1=02000000#40...Ack Packet received: OK [...] (gdb) show stub-supports-P-packet stub-supports-P-packet is auto-detected, currently supported > As for names, it probably should have "remote" in the name to tie it > to the other remote protocol variables. Perhaps: > > remote-stub-supports-P-packet > remote-protocol-supports-P-packet > remote-protocol-supports-register-set remote-protocol-P-packet {supported,unsupported,auto} plus a ``{show,info} remote-protocol''. > But that's only if there really is a need for this variable. We > shouldn't add knobs just because we can. I think that there should at least be a display mechanism so that the user can determine if the packet is being used. The enable/disable is there so that the user can control the probe. While I don't expect the average engineer to be remotly interested in this I would expect an engineer testing a stub to make use of it. Rather than ``class_obscure'' the command should probably be ``class_maintenance''. enjoy, Andrew (Hmm, things to do today - document the command). >From shebs@cygnus.com Wed Jul 07 18:17:00 1999 From: Stan Shebs To: eliz@delorie.com Cc: gdb-patches@sourceware.cygnus.com Subject: Re: [eliz@is.elta.co.il: GDB: fine print in 387 info] Date: Wed, 07 Jul 1999 18:17:00 -0000 Message-id: <199907080117.SAA16963@andros.cygnus.com> References: <199907071328.JAA06637@indy.delorie.com> X-SW-Source: 1999-q3/msg00014.html Content-length: 1770 Date: Wed, 7 Jul 1999 09:28:47 -0400 (EDT) From: Eli Zaretskii IMHO, all the different versions of x87 support on the various platforms, at least as far as GDB 4.18 sources go, are so close to one another that they almost cry for unification. I compared all of them at some point, and they all seem like 95% cut-and-paste and 5% platform-dependent stuff. (And some of the platform-dependencies are just incompatibilities in the order that the FP registers are enumerated in the header files.) I think it should be very easy to write a bunch of macros that would hide any *real* platform-dependent aspects, like how you get the registers from the debuggee, and use platform-independent code for everything else. I agree that we ought to be sharing some code here. It's worth considering whether this ought to be done with macros or with the new architecture machinery; macros still make sense if the mods are purely for native support, but you should use functions for anything that might be used for cross-debugging. Another way to look at it is - suppose you were running a cross GDB hosted on djgpp targeting the Hurd? (Don't laugh, stranger configs have happened!) If people agree, the first step in the right direction would be to agree on the layout of the information produced by "info float". The new code on i387-tdep.c is different from all the other platforms in this respect. I can't think of a reason why users would want to have "info float" display different things on different hosts, since it's supposed to show info about the FPU, not the OS. Unless someone can work up a counterexample, let's define (and document) a single layout, and work from that. Stan