Re: RDI target broken in 000215 snapshot

[Fernando Nasser <fnasser@cygnus.com>]

Grant Edwards wrote:
> 
> On Tue, Feb 22, 2000 at 03:36:52PM +0000, Fernando Nasser wrote:
> 
> > > The RDI target support seems to be broken in the 000215
> > > snapshot.
> >
> > Can you be more specific?  It is working right with the AEB board and
> > with another one I have here.  Both use serial ports.
> 
> (I'm now using 000222)
> 
> When I download code with the "load" command, the byte order of
> the data gets flipped -- it ends up in little-endian order
> (it's big-endian in the file, and I need it to stay that way
> when it is downloaded). Downloading with a patched 4.18 doesn't
> have this problem.
> 
Grant,

A few questions (while I rebuild from the 22 sources):

What compiler, in what host and with which parameters did you generate your executable file?

Is it the same one you can successifuly load with the patched 4.18?

In both cases you are loading the program into the AEB board, right?

I forgot, which host are you running gdb in?  Linux, Solaris, Cygwin?

Thanks,
Fernando


-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@cygnus.com
2323 Yonge Street, Suite #300           Tel:  416-482-2661 ext. 311
Toronto, Ontario   M4P 2C9              Fax:  416-482-6299
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Jim Kingdon <kingdon@redhat.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: [MAINT/RFC] Start devolving maintenance responsibility
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38C22262.FFA0191@cygnus.com>
References: <38BC81A0.17D25C8@cygnus.com> <bbt4y3s8k.fsf@rtl.cygnus.com> <38BE146B.46ED6E4D@cygnus.com> <200003021446.JAA31093@devserv.devel.redhat.com>
X-SW-Source: 2000-q1/msg00546.html
Content-length: 1917

Jim Kingdon wrote:
> 
> > Sorry, devolve, as a word, is probably more meaningful to people from
> > Commonwealth countries.
> 
> I'm familiar with the word (e.g. Scotland) but at least for me it has
> all these connotations of national sovereignty and power and such.
> For example, it is a dead end to assume that an OS vendor should
> automatically maintain GDB on that OS because they "own" the platform
> or something.
> 
> > The underlying concern I have isn't with people like you that have been
> > hacking on open code for years, its with people familar with GDB but not
> > so familar with open source.  For that reason, I think it is useful to
> > spell out, in basic terms, how the system should work.
> 
> Maybe link to The Cathedral and the Bazaar (which is well known) and
> Alan Cox's Town Council paper (which deserves to be better known and
> is at http://slashdot.org/features/98/10/13/1423253.shtml )?  I was
> just showing the Town Council paper to someone in a GDB context and it
> seemed to resonate.
> 
> I'm sure the looseness of this approach will make some people nervous.
> But you can't build trust through rules and policies either.  What is
> going to turn GDB development into the (more) vibrant community we
> want it to be is delivering on the promises to add maintainers and
> otherwise open up.  We've made great progress in the last month and
> let's keep it up.

Try this:

``
Note individuals who maintain parts of the debugger need approval to
check in changes outside of the immediate domain that they maintain.

If there is no maintainer for a given domain then the responsibility
falls to the head maintainer.

If there are several maintainers for a given domain then
responsibility falls to the first maintainer.  The first maintainer is
free to devolve maintainership responsibility anyway they like.

Refs: http://slashdot.org/features/98/10/13/1423253.shtml

''

	Andrew
From eliz@delorie.com Sat Apr 01 00:00:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: ezannoni@cygnus.com
Cc: muller@cerbere.u-strasbg.fr, gdb@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: Buffering problems with "gdb < foo"
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003080948.EAA16456@indy.delorie.com>
References: <200003070845.JAA27855@cerbere.u-strasbg.fr> <200003070851.DAA14463@indy.delorie.com> <14533.8241.716311.478074@kwikemart.cygnus.com>
X-SW-Source: 2000-q1/msg00593.html
Content-length: 2259

> This input_from_terminal_p() function does:
> 
> int
> input_from_terminal_p ()
> {
>   return gdb_has_a_terminal () && (instream == stdin) & caution;
> }
> 
> In my case the gdb_has_a_terminal() returns 0, so the query is not asked.
> 
> All seems to work fine fro solaris. What happens on DJGPP? Is
> gdb_has_a terminal() returning 1, maybe?

Yes, gdb_has_a_terminal returned 1 in the DJGPP case.

This turned to be due to a problem in ser-go32.c: it doesn't support
standard handles (those which are connected to a terminal in an
interactive session), whereas GDB expects it to.

I don't know why does gdb_has_a_terminal go through serial.c to find
out about GDB's own the controlling terminal--won't it be easier (and
more portable) just to use isatty?

Anyway, the patch to make the current code in gdb_has_a_terminal work
is below.


2000-03-07  Eli Zaretskii  <eliz@is.elta.co.il>

	* ser-go32.c (dos_get_tty_state): Fail if the (fake) handle was
	not opened by dos_open, but let the 3 standard handles go through
	unharmed.

--- gdb/ser-go32.c~0	Wed Feb 23 17:18:50 2000
+++ gdb/ser-go32.c	Tue Mar  7 22:19:34 2000
@@ -488,6 +488,10 @@ dos_open (scb, name)
       return -1;
     }
 
+  /* FIXME: this is a Bad Idea (tm)!  One should *never* invent file
+     handles, since they might be already used by other files/devices.
+     The Right Way to do this is to create a real handle by dup()'ing
+     some existing one.  */
   fd = name[3] - '1';
   port = &ports[fd];
   if (port->refcnt++ > 0)
@@ -650,6 +654,19 @@ dos_get_tty_state (scb)
   struct dos_ttystate *port = &ports[scb->fd];
   struct dos_ttystate *state;
 
+  /* Are they asking about a port we opened?  */
+  if (port->refcnt <= 0)
+    {
+      /* We've never heard about this port.  We should fail this call,
+	 unless they are asking about one of the 3 standard handles,
+	 in which case we pretend the handle was open by us if it is
+	 connected to a terminal device.  This is beacuse Unix
+	 terminals use the serial interface, so GDB expects the
+	 standard handles to go through here.  */
+      if (scb->fd >= 3 || !isatty (scb->fd))
+	return NULL;
+    }
+
   state = (struct dos_ttystate *) xmalloc (sizeof *state);
   *state = *port;
   return (serial_ttystate) state;