From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: Fernando Nasser Cc: Mark Salter , gdb@sources.redhat.com Subject: Re: gdb/remote - I/O Date: Thu, 29 Mar 2001 16:27:00 -0000 Message-id: <3AC0DA82.24A528AD@cygnus.com> References: <3ABBDDE4.7C22709D@cygnus.com> <200103261830.f2QIU2614825@deneb.localdomain> <3ABF9077.DFC22AE7@cygnus.com> <200103261954.f2QJsBg15093@deneb.localdomain> <3ABFA8D1.DA0D2EAE@redhat.com> <3AC0C9DF.CB1BC2D9@cygnus.com> <3AC0CBF6.C50C1827@redhat.com> X-SW-Source: 2001-03/msg00302.html > It is not "overloading". The meaning of SIGTTIN is _exactly_ a request > for read from the terminal from a process that does not have immediate > access to the terminal (being in the background is the native version of > this situation). It is used to tell whoever (if someone) can help this > program to have the input it needs. In this case it is GDB as it is > acting as it has the "console" for that program. Remember, GDB doesn't necessarily own the terminal that the user is trying to get input/output through. The process could be directly attached to a real tty/pty and that could be separatly be triggering the SIGTTIN. Andrew >From RDBrown@mira.net Thu Mar 29 16:27:00 2001 From: RDBrown@mira.net To: gdb@sources.redhat.com, gdb-patches@sources.redhat.com Subject: gdb March 2001 archive Date: Thu, 29 Mar 2001 16:27:00 -0000 Message-id: X-SW-Source: 2001-03/msg00298.html Content-length: 1288 The gdb Mar 2001 archive hasn't moved past March 21 - is the mail getting through or is it just the archive? What do you want loaded on the testresults page? gdb/testsuite/gdb.log or gdb/testsuite/gdb.sum? Building from the 0324 snapshot on alpha-dec-osf4.0e and i586-sco-sysv5uw7.1.0 somewhat required the following patch - which should be done with autoconf. Both provide NSIG but only if _XOPEN_SOURCE etc are undefined. (Both using gcc-2.95.2) On alpha-dec-osf4.0e the link failed missing `in_solib_dynsym_resolve_code'. /usr/bin/ld: Unresolved: in_solib_dynsym_resolve_code collect2: ld returned 1 exit status --- expect/exp_trap.c.orig Tue Mar 27 00:17:00 2001 +++ expect/exp_trap.c Mon Mar 26 13:18:59 2001 @@ -22,6 +22,12 @@ #ifndef NSIG #ifdef _NSIG #define NSIG _NSIG +#else +#ifdef __osf__ /* alpha-dec-osf4.0e workaround */ +#define NSIG 49 +#else /* i586-sco-sysv5uw7.1.0 workaround */ +#define NSIG 35 +#endif #endif #endif --- expect/exp_command.c.orig Tue Mar 27 00:17:15 2001 +++ expect/exp_command.c Mon Mar 26 13:18:50 2001 @@ -53,6 +53,12 @@ #ifndef NSIG #ifdef _NSIG #define NSIG _NSIG +#else +#ifdef __osf__ /* alpha-dec-osf4.0e workaround */ +#define NSIG 49 +#else /* i586-sco-sysv5uw7.1.0 workaround */ +#define NSIG 35 +#endif #endif #endif >From ac131313@cygnus.com Thu Mar 29 16:27:00 2001 From: Andrew Cagney To: Fernando Nasser Cc: Mark Salter , gdb@sources.redhat.com Subject: Re: gdb/remote - I/O Date: Thu, 29 Mar 2001 16:27:00 -0000 Message-id: <3AC0C9DF.CB1BC2D9@cygnus.com> References: <3ABBDDE4.7C22709D@cygnus.com> <200103261830.f2QIU2614825@deneb.localdomain> <3ABF9077.DFC22AE7@cygnus.com> <200103261954.f2QJsBg15093@deneb.localdomain> <3ABFA8D1.DA0D2EAE@redhat.com> X-SW-Source: 2001-03/msg00300.html Content-length: 658 Fernando Nasser wrote: > > I guess Mark found a way to preserve the Request-Response nature of the > protocol while processing input without the need of an interrupt. > > When the target program issues a read from the console, the stub should > stop it and send a "T" packet with SIGTTIN (read on terminal by > background process). > > This reflects what really happens. The application will probably issue > a prompt ("O" packets) and then will need input and will have to halt > and wait for it. I don't think trying to overload SIGTTIN is correct. A remote UNIX process could get that for reasons other than needing to get input from GDB> Andrew >From fche@redhat.com Thu Mar 29 16:27:00 2001 From: fche@redhat.com (Frank Ch. Eigler) To: jtc@redback.com Cc: Andrew Cagney , GDB Discussion Subject: Re: gdb/remote - I/O Date: Thu, 29 Mar 2001 16:27:00 -0000 Message-id: References: <3ABBDDE4.7C22709D@cygnus.com> <5mhf0fov3q.fsf@jtc.redback.com> X-SW-Source: 2001-03/msg00309.html Content-length: 2008 jtc wrote: : [...] : Truth be told, I've never used GDB's output packet. I wonder if you're in a minority! : Most targets, even the cheap eval boards available for low end : microcontrollers have more than one I/O channel, so I use one for : GDB and another for system I/O. >From the point of view of test suites and similar automated control, the fewer physical connections, the better. Several remote debugging protocols include console I/O already; we would like to finally bring "remote" closer. : But if I needed to route I/O through GDB, I think I'd want some- : thing richer than a single serial i/o stream. Perhaps some sort of : lightweight filesystem layer with open/read/write/close primitives. : [...] If we're going to change the protocol, why not make it something : richer than a single stream? [...] Yes, this would be a worthwhile exercise, but is way outside the realm of reasonably small extensions of the remote protocol. : [...] : At present, remote_stop() is implemented, depending on the value of : the remote_break variable, by either a CNTRL-C or a serial break. : Both suffer from a lack of acknowledgement from the target. [...] The lack of a timely response (S/T packet) is an implicit NAK. : If it's only a console, please explain why this is valuable in the : real world (as opposed to a toy/trade-show booth demo). If it's : something better, the latency is going to kill you. It's "real world" useful for - test suites - fast targets (eg. simulators) : Andrew> Flow control is a target problem. That data gets sent across, : Andrew> ready or not :-) : : I think discounts the problem too easily. [...] In effect, this : requires the agent to be deeply entertwined with target i/o. That's true, though some degree of intertwining was always involved in supporting ordinary output packets. FWIW, I like Fernando's idea of signalling blocking reads by target stops, i.e., a "pull" model for input. It would reduce the need for flow control. - FChE >From ac131313@cygnus.com Thu Mar 29 16:27:00 2001 From: Andrew Cagney To: Steven Johnson Cc: Fernando Nasser , Steven Johnson , gdb@sources.redhat.com Subject: Re: Register Cache. Date: Thu, 29 Mar 2001 16:27:00 -0000 Message-id: <3ABFE1FA.22F1C66B@cygnus.com> References: <8AE4B526B977D411841F00A0CC334020052C28@cuz-exchange.sdesigns.net> <39AC598A.DFAF67E9@ozemail.com.au> <3ABF562F.2144AF18@cygnus.com> <3ABF5DF9.4D630216@redhat.com> <3ABFD062.17EDADAF@neurizon.net> X-SW-Source: 2001-03/msg00294.html Content-length: 601 Steven Johnson wrote: > I have gotten around the issues by invalidating the register cache > between writes. This is obviously sub-optimal but it works OK. Very sub-optimal. Being able to blat register_valid[] is going away :-) > A better implementation would be to allow a setting on a register by > register basis that sets how it will be cached by reg-cache. At the > time of the original post, this was a fairly major undertaking. > Regcache currently seems to be undergoing changes that will make > implementing this easier but for the moment flushing works fine. I hope it helps. Andrew >From fnasser@redhat.com Thu Mar 29 16:27:00 2001 From: Fernando Nasser To: Mark Salter Cc: ac131313@cygnus.com, gdb@sources.redhat.com Subject: Re: gdb/remote - I/O Date: Thu, 29 Mar 2001 16:27:00 -0000 Message-id: <3ABFA8D1.DA0D2EAE@redhat.com> References: <3ABBDDE4.7C22709D@cygnus.com> <200103261830.f2QIU2614825@deneb.localdomain> <3ABF9077.DFC22AE7@cygnus.com> <200103261954.f2QJsBg15093@deneb.localdomain> X-SW-Source: 2001-03/msg00292.html Content-length: 1162 I guess Mark found a way to preserve the Request-Response nature of the protocol while processing input without the need of an interrupt. When the target program issues a read from the console, the stub should stop it and send a "T" packet with SIGTTIN (read on terminal by background process). This reflects what really happens. The application will probably issue a prompt ("O" packets) and then will need input and will have to halt and wait for it. However, this now puts GDB in an "inferior input" state, as state that we did not have before). At what level will this be handled? There are several details that have to be sorted out as well, like if the "i" packet does not have all the input needed by the read to continue what should the target do? Maybe issue another "T" until it gets all the data it needs. On the other extreme the user may have typed ahead. We can just have the stub discard those (but if we have echoed the characters typed on the GDB console this can be confusing). -- Fernando Nasser Red Hat Canada Ltd. E-Mail: fnasser@redhat.com 2323 Yonge Street, Suite #300 Toronto, Ontario M4P 2C9 >From dolson@dotcast.com Thu Mar 29 16:27:00 2001 From: "Dan Olson (Seattle)" To: "'gdb@sourceware.cygnus.com'" Subject: Hacking gdb and binutils (gas especially) Date: Thu, 29 Mar 2001 16:27:00 -0000 Message-id: X-SW-Source: 2001-03/msg00305.html Content-length: 504 Hi all, What is the best way to get a matched version of gdb and gas,binutils. I'm tweaking BFD and opcodes and want gdb and gas to share the same libs. Right now I'm am trying to use binutils-2.10.1 with the gdb-5.0 unique directories moved in. Seems to kinda work but some targets I don't care about won't build (sim/v850 - I see the problem is having libintl linked in). Is there a better way to get a src tree with both gdb and binutils that all play together? -- Dan Olson dolson@dotcast.com