[PATCH]: Fix ser-go32.c for UARTs with FIFOs.

[PATCH]: Fix ser-go32.c for UARTs with FIFOs.

[Eli Zaretskii]

FYI: I committed today the following patch:

2001-02-04  Eli Zaretskii  <eliz@is.elta.co.il>

	* ser-go32.c (dos_write) [UART_FIFO_WORKS]: Use outportsb only if
	UART_FIFO_WORKS is defined.  Otherwise use outportb.
	From Francisco Pastor <fpastor.etra-id@etra.es>

--- gdb/ser-go32.c~0	Sun Jul 30 04:48:26 2000
+++ gdb/ser-go32.c	Sat Feb  3 19:49:06 2001
@@ -796,9 +796,16 @@ dos_write (serial_t scb, const char *str
       /* send the data, fifosize bytes at a time */
       cnt = fifosize > len ? len : fifosize;
       port->txbusy = 1;
+      /* Francisco Pastor <fpastor.etra-id@etra.es> says OUTSB messes
+	 up the communications with UARTs with FIFOs.  */
+#ifdef UART_FIFO_WORKS
       outportsb (port->base + com_data, str, cnt);
       str += cnt;
       len -= cnt;
+#else
+      for ( ; cnt > 0; cnt--, len--)
+	outportb (port->base + com_data, *str++);
+#endif
 #ifdef DOS_STATS
       cnts[CNT_TX] += cnt;
 #endif
From eliz@is.elta.co.il Sat Feb 03 23:54:00 2001
From: Eli Zaretskii <eliz@is.elta.co.il>
To: gdb-patches@sourceware.cygnus.com
Subject: [PATCH]: Avoid invoking DOS/Windows FIND.EXE
Date: Sat, 03 Feb 2001 23:54:00 -0000
Message-id: <Pine.SUN.3.91.1010204095122.20547R-100000@is>
X-SW-Source: 2001-02/msg00039.html
Content-length: 841

FYI: I committed today the following patch to djconfig.sh:

2001-02-04  Eli Zaretskii  <eliz@is.elta.co.il>

	* config/djgpp/djconfig.sh: Use explicit absolute file name when
	invoking `find'.

--- gdb/config/djgpp/djconfig.s~0	Mon May  8 18:06:26 2000
+++ gdb/config/djgpp/djconfig.sh	Sat Feb  3 21:02:16 2001
@@ -59,8 +59,11 @@
   SKIPDIR=`pwd | sed -e "s|${srcdir}|.|"`
   SKIPFILES="${SKIPDIR}/*"
 fi
+
+# We use explicit /dev/env/DJDIR/bin/find to avoid catching
+# an incompatible DOS/Windows version that might be on their PATH.
 for fix_dir in \
-  `cd $srcdir && find . -type d ! -ipath "${SKIPDIR}" ! -ipath "${SKIPFILES}"`
+  `cd $srcdir && /dev/env/DJDIR/bin/find . -type d ! -ipath "${SKIPDIR}" ! -ipath "${SKIPFILES}"`
 do
   if test ! -f ${fix_dir}/configure.orig ; then
     if test -f ${srcdir}/${fix_dir}/configure ; then

Re: [PATCH]: Fix ser-go32.c for UARTs with FIFOs.

[Eli Zaretskii]

> From: jtc@redback.com (J.T. Conklin)
> Date: 06 Feb 2001 11:44:07 -0800
> 
> Eli mentioned that he didn't think the speed gain from using OUTS 
> vs. OUT was significant.

My reasoning was that the current CPUs can run circles around any UART
anyway, so even with OUTS you will most of the time wait for the UART
to finish transmitting.

> If that is really the case, why not use the conservative approach
> and always use OUT?

Yes, that was what I meant to do.  Except that I don't like to remove
old code all of a sudden, so I kinda deprecated it with an #ifdef.
From msokolov@ivan.Harhan.ORG Tue Feb 06 12:45:00 2001
From: msokolov@ivan.Harhan.ORG (Michael Sokolov)
To: gdb-patches@sources.redhat.com
Subject: [patch] to gdb: portability fix: <sys/file.h>
Date: Tue, 06 Feb 2001 12:45:00 -0000
Message-id: <0102062042.AA24128@ivan.Harhan.ORG>
X-SW-Source: 2001-02/msg00086.html
Content-length: 3125

Hi there,

The patch below is a portability fix for gdb. corelow.c uses F_OK and currently
fails to compile on 4.3BSD host because it doesn't include <sys/file.h>, where
this constant is defined on 4.3BSD. The patch below makes it include
<sys/file.h> if present, and adds the configure check for it. OK to commit?

-- 
Michael Sokolov
Public Service Agent
International Engineering and Science Task Force

1351 VINE AVE APT 27		Phone: +1-714-738-5409
FULLERTON CA 92833-4291 USA	(home office)

E-mail: msokolov@ivan.Harhan.ORG (ARPA TCP/SMTP)

2001-02-06  Michael Sokolov  <msokolov@ivan.Harhan.ORG>

	* configure.in (AC_CHECK_HEADERS): Add sys/file.h.
	* configure, config.in: Regenerate.
	* corelow.c: Include <sys/file.h> if present.

Index: configure.in
===================================================================
RCS file: /cvs/src/src/gdb/configure.in,v
retrieving revision 1.55
diff -p -r1.55 configure.in
*** configure.in	2001/01/31 02:08:23	1.55
--- configure.in	2001/02/06 20:26:30
***************
*** 1,5 ****
  dnl Autoconf configure script for GDB, the GNU debugger.
! dnl Copyright 1995, 1996, 1997, 1998, 1999, 2000 Free Software Foundation, Inc.
  dnl
  dnl This file is part of GDB.
  dnl 
--- 1,6 ----
  dnl Autoconf configure script for GDB, the GNU debugger.
! dnl Copyright 1995, 1996, 1997, 1998, 1999, 2000,
! dnl 2001 Free Software Foundation, Inc.
  dnl
  dnl This file is part of GDB.
  dnl 
*************** AC_CHECK_HEADERS(ctype.h endian.h link.h
*** 122,128 ****
  	string.h sys/procfs.h sys/ptrace.h sys/reg.h stdint.h \
  	term.h termio.h termios.h unistd.h wait.h sys/wait.h \
  	wchar.h wctype.h asm/debugreg.h sys/debugreg.h sys/select.h \
! 	time.h sys/ioctl.h sys/user.h \
  	dirent.h sys/ndir.h sys/dir.h ndir.h \
  	curses.h ncurses.h \
  	poll.h sys/poll.h)
--- 123,129 ----
  	string.h sys/procfs.h sys/ptrace.h sys/reg.h stdint.h \
  	term.h termio.h termios.h unistd.h wait.h sys/wait.h \
  	wchar.h wctype.h asm/debugreg.h sys/debugreg.h sys/select.h \
! 	time.h sys/file.h sys/ioctl.h sys/user.h \
  	dirent.h sys/ndir.h sys/dir.h ndir.h \
  	curses.h ncurses.h \
  	poll.h sys/poll.h)
Index: corelow.c
===================================================================
RCS file: /cvs/src/src/gdb/corelow.c,v
retrieving revision 1.11
diff -p -r1.11 corelow.c
*** corelow.c	2000/12/15 01:01:46	1.11
--- corelow.c	2001/02/06 20:26:32
***************
*** 1,5 ****
  /* Core dump and executable file functions below target vector, for GDB.
!    Copyright 1986, 87, 89, 91, 92, 93, 94, 95, 96, 97, 1998, 2000
     Free Software Foundation, Inc.
  
     This file is part of GDB.
--- 1,5 ----
  /* Core dump and executable file functions below target vector, for GDB.
!    Copyright 1986, 87, 89, 91, 92, 93, 94, 95, 96, 97, 1998, 2000, 2001
     Free Software Foundation, Inc.
  
     This file is part of GDB.
***************
*** 24,29 ****
--- 24,32 ----
  #include <errno.h>
  #include <signal.h>
  #include <fcntl.h>
+ #ifdef HAVE_SYS_FILE_H
+ #include <sys/file.h>
+ #endif
  #include "frame.h"		/* required by inferior.h */
  #include "inferior.h"
  #include "symtab.h"
From msokolov@ivan.Harhan.ORG Tue Feb 06 12:50:00 2001
From: msokolov@ivan.Harhan.ORG (Michael Sokolov)
To: gdb-patches@sources.redhat.com
Subject: [patch] to gdb: obviously correct fix for some #ifdef HAVE_SGTTY code
Date: Tue, 06 Feb 2001 12:50:00 -0000
Message-id: <0102062047.AA24164@ivan.Harhan.ORG>
X-SW-Source: 2001-02/msg00087.html
Content-length: 1608

Hi there,

The patch below is an obviously correct fix to a line of obviously broken non-
compilable code. (The line in question is in #ifdef HAVE_SGTTY, though, which
is why you spoiled children not using 4.3BSD have never noticed it. :-) OK to
commit?

-- 
Michael Sokolov
Public Service Agent
International Engineering and Science Task Force

1351 VINE AVE APT 27		Phone: +1-714-738-5409
FULLERTON CA 92833-4291 USA	(home office)

E-mail: msokolov@ivan.Harhan.ORG (ARPA TCP/SMTP)

2001-02-06  Michael Sokolov  <msokolov@ivan.Harhan.ORG>

	* ser-unix.c (hardware_print_tty_state) [HAVE_SGTTY]: Call
	fprintf_filtered with correct arguments.

Index: ser-unix.c
===================================================================
RCS file: /cvs/src/src/gdb/ser-unix.c,v
retrieving revision 1.10
diff -p -r1.10 ser-unix.c
*** ser-unix.c	2001/02/02 19:14:33	1.10
--- ser-unix.c	2001/02/06 20:27:06
*************** hardwire_print_tty_state (serial_t scb,
*** 267,273 ****
    fprintf_filtered (stream, "tchars: ");
    for (i = 0; i < (int) sizeof (struct tchars); i++)
      fprintf_filtered (stream, "0x%x ", ((unsigned char *) &state->tc)[i]);
!   fprintf_filtered ("\n");
  
    fprintf_filtered (stream, "ltchars: ");
    for (i = 0; i < (int) sizeof (struct ltchars); i++)
--- 267,273 ----
    fprintf_filtered (stream, "tchars: ");
    for (i = 0; i < (int) sizeof (struct tchars); i++)
      fprintf_filtered (stream, "0x%x ", ((unsigned char *) &state->tc)[i]);
!   fprintf_filtered (stream, "\n");
  
    fprintf_filtered (stream, "ltchars: ");
    for (i = 0; i < (int) sizeof (struct ltchars); i++)
From jtc@redback.com Tue Feb 06 13:31:00 2001
From: jtc@redback.com (J.T. Conklin)
To: msokolov@ivan.Harhan.ORG (Michael Sokolov)
Cc: gdb-patches@sources.redhat.com
Subject: Re: [patch] to gdb: portability fix: <sys/file.h>
Date: Tue, 06 Feb 2001 13:31:00 -0000
Message-id: <5melxbsdmd.fsf@jtc.redback.com>
References: <0102062042.AA24128@ivan.Harhan.ORG>
X-SW-Source: 2001-02/msg00088.html
Content-length: 1538

>>>>> "Michael" == Michael Sokolov <msokolov@ivan.Harhan.ORG> writes:
Michael> The patch below is a portability fix for gdb. corelow.c uses
Michael> F_OK and currently fails to compile on 4.3BSD host because it
Michael> doesn't include <sys/file.h>, where this constant is defined
Michael> on 4.3BSD. The patch below makes it include <sys/file.h> if
Michael> present, and adds the configure check for it. OK to commit?

There are some configs with xm-*.h headers that define F_OK, etc.  I
don't think that's a satisfactory solution considering we want to
obsolete as much as we can of these with autoconf tests.

In that sense your change is better than what has been traditionally
done in this situation.  However, I am somewhat concerned if any one
changes any other file to use one of the access(2) macros (F_OK, R_OK,
W_OK, or X_OK) it won't have your fix.

One thing we've done is to provide GDB specific wrappers of header
files, fixing up nits or deficiencies of different implementations so
that the body of GDB code doesn't have to deal with them.  I'm
inclined to think that this falls within that category.  We could
create a gdb_unistd.h that simply includes unistd.h on systems that
have that header, but defines the missing bits on others.  We could
fix up those other gdb configs at the same time.

Note this isn't a patch rejection.  I'm not in a position to do that.
So before you go about and do this work, make sure there is consensus
that this route is the way to go.

        --jtc

-- 
J.T. Conklin
RedBack Networks
From jtc@redback.com Tue Feb 06 13:31:00 2001
From: jtc@redback.com (J.T. Conklin)
To: msokolov@ivan.Harhan.ORG (Michael Sokolov)
Cc: gdb-patches@sources.redhat.com
Subject: Re: [patch] to gdb: obviously correct fix for some #ifdef HAVE_SGTTY code
Date: Tue, 06 Feb 2001 13:31:00 -0000
Message-id: <5mae7zsdle.fsf@jtc.redback.com>
References: <0102062047.AA24164@ivan.Harhan.ORG>
X-SW-Source: 2001-02/msg00089.html
Content-length: 413

>>>>> "Michael" == Michael Sokolov <msokolov@ivan.Harhan.ORG> writes:
Michael> The patch below is an obviously correct fix to a line of
Michael> obviously broken non- compilable code. (The line in question
Michael> is in #ifdef HAVE_SGTTY, though, which is why you spoiled
Michael> children not using 4.3BSD have never noticed it. :-) OK to
Michael> commit?

OK.

        --jtc

-- 
J.T. Conklin
RedBack Networks
From msokolov@ivan.Harhan.ORG Tue Feb 06 13:53:00 2001
From: msokolov@ivan.Harhan.ORG (Michael Sokolov)
To: gdb-patches@sources.redhat.com
Subject: Re: [patch] to gdb: portability fix: <sys/file.h>
Date: Tue, 06 Feb 2001 13:53:00 -0000
Message-id: <0102062150.AA24428@ivan.Harhan.ORG>
X-SW-Source: 2001-02/msg00090.html
Content-length: 1621

jtc@redback.com (J.T. Conklin) wrote:

> However, I am somewhat concerned if any one
> changes any other file to use one of the access(2) macros (F_OK, R_OK,
> W_OK, or X_OK) it won't have your fix.

Anyone needing a define that's in different places on different systems should
have logic to include different headers depending on config.h definitions. This
is how it's done in the rest of the Cygnus tree.

> One thing we've done is to provide GDB specific wrappers of header
> files, fixing up nits or deficiencies of different implementations so
> that the body of GDB code doesn't have to deal with them.  I'm
> inclined to think that this falls within that category.  We could
> create a gdb_unistd.h that simply includes unistd.h on systems that
> have that header, but defines the missing bits on others.  We could
> fix up those other gdb configs at the same time.

But this is not a problem of a specific header file being broken that can be
wrappered around, it's just that the definitions of access(2) macros are in
different headers on different systems. I guess the logic for including these
headers could be put in defs.h. This is also consistent with how the rest of
the Cygnus tree handles this.

> Note this isn't a patch rejection.

So could you then approve my patch as a blanket write priv maintainer? Or would
you rather have me add the access(2) macro logic in defs.h?

-- 
Michael Sokolov
Public Service Agent
International Engineering and Science Task Force

1351 VINE AVE APT 27		Phone: +1-714-738-5409
FULLERTON CA 92833-4291 USA	(home office)

E-mail: msokolov@ivan.Harhan.ORG (ARPA TCP/SMTP)
From jtc@redback.com Tue Feb 06 14:35:00 2001
From: jtc@redback.com (J.T. Conklin)
To: msokolov@ivan.Harhan.ORG (Michael Sokolov)
Cc: gdb-patches@sources.redhat.com
Subject: Re: [patch] to gdb: portability fix: <sys/file.h>
Date: Tue, 06 Feb 2001 14:35:00 -0000
Message-id: <5mvgqnqw3j.fsf@jtc.redback.com>
References: <0102062150.AA24428@ivan.Harhan.ORG>
X-SW-Source: 2001-02/msg00091.html
Content-length: 2961

>>>>> "Michael" == Michael Sokolov <msokolov@ivan.Harhan.ORG> writes:
>> However, I am somewhat concerned if any one changes any other file
>> to use one of the access(2) macros (F_OK, R_OK, W_OK, or X_OK) it
>> won't have your fix.

Michael> Anyone needing a define that's in different places on
Michael> different systems should have logic to include different
Michael> headers depending on config.h definitions. This is how it's
Michael> done in the rest of the Cygnus tree.

I'm puzzled what you mean by the Cygnus tree.  While the master GDB
repository was once Cygnus' internal development tree, it was split
out quite some time ago.

If you mean that binutils, etc. add feature tests to each file that
might need a macro definition, I say "great, if it works for them".
GDB used a similar scheme 5 or so years ago.  It was changed to use
the gdb_*.h headers at that time because we constantly encountered
platforms where the #ifdefs that used autoconf feature tests were
missing, or broken, or different, between files.  IMHO, the new scheme
has proven to be robust.

>> One thing we've done is to provide GDB specific wrappers of header
>> files, fixing up nits or deficiencies of different implementations so
>> that the body of GDB code doesn't have to deal with them.  I'm
>> inclined to think that this falls within that category.  We could
>> create a gdb_unistd.h that simply includes unistd.h on systems that
>> have that header, but defines the missing bits on others.  We could
>> fix up those other gdb configs at the same time.

Michael> But this is not a problem of a specific header file being
Michael> broken that can be wrappered around, it's just that the
Michael> definitions of access(2) macros are in different headers on
Michael> different systems. I guess the logic for including these
Michael> headers could be put in defs.h. This is also consistent with
Michael> how the rest of the Cygnus tree handles this.

While one way to interpret the gdb_*.h headers is to fix up broken
headers, a broader (and IMO more useful) interpretation is that the
gdb_*.h headers define a programming interface for the rest of GDB.
So it doesn't matter that a target's unistd.h header (if it even has a
unistd.h header) doesn't define F_OK, etc.  The rest of GDB can depend
on F_OK being defined if gdb_unistd.h is included.

>> Note this isn't a patch rejection.

Michael> So could you then approve my patch as a blanket write priv
Michael> maintainer? Or would you rather have me add the access(2)
Michael> macro logic in defs.h?

I think I'm allowed to approve the patch (I'm kinda new at this role,
so I'm still figuring things out).  But I want to see what Andrew &
others think.  I'm sure within a short time a decision will be made
as to what type of patch will be acceptable.

However, any further involvement by me will have to wait until later.
I've got a head cold and am heading home...

        --jtc

-- 
J.T. Conklin
RedBack Networks
From msokolov@ivan.Harhan.ORG Tue Feb 06 15:04:00 2001
From: msokolov@ivan.Harhan.ORG (Michael Sokolov)
To: gdb-patches@sources.redhat.com
Subject: Re: [patch] to gdb: portability fix: <sys/file.h>
Date: Tue, 06 Feb 2001 15:04:00 -0000
Message-id: <0102062301.AA24682@ivan.Harhan.ORG>
X-SW-Source: 2001-02/msg00092.html
Content-length: 1730

jtc@redback.com (J.T. Conklin) wrote:

> I'm puzzled what you mean by the Cygnus tree.

Please don't pretend that you don't know. I know all about your conspiracy.

ftp://ivan.Harhan.ORG/pub/embedded/cygnus-tree-intro

> If you mean that binutils, etc. add feature tests to each file that
> might need a macro definition, I say "great, if it works for them".

They use either that or a single file, usually called system.h, which does all
this and is included by everybody or almost everybody.

> While one way to interpret the gdb_*.h headers is to fix up broken
> headers, a broader (and IMO more useful) interpretation is that the
> gdb_*.h headers define a programming interface for the rest of GDB.

Then why have many gdb_*.h files rather than one system.h file? How would this
goo be divided between different gdb_*.h files? Why should the F_OK logic be in
gdb_unistd.h and not gdb_sys_file.h? Only because you politically favor systems
with this define in <unistd.h> over those with this define in <sys/file.h>?

If that's the route you want to take, someone else will have to do the work, as
I won't be qualified for this. For me true centerline UNIX == V7/4.3BSD, and if
you want to structure gdb's headers along the lines of SysV/POSIX/whatever, I
would have no idea and no desire to learn whether F_OK is supposed to be in
unistd.h or in fcntl.h or wherever by your "standards".

But in the meantime I want gdb to build on 4.3BSD.

> But I want to see what Andrew &
> others think.

Guys?

-- 
Michael Sokolov
Public Service Agent
International Engineering and Science Task Force

1351 VINE AVE APT 27		Phone: +1-714-738-5409
FULLERTON CA 92833-4291 USA	(home office)

E-mail: msokolov@ivan.Harhan.ORG (ARPA TCP/SMTP)
From dj@redhat.com Tue Feb 06 16:25:00 2001
From: DJ Delorie <dj@redhat.com>
To: gdb-patches@sources.redhat.com
Cc: msokolov@ivan.Harhan.ORG (Michael Sokolov)
Subject: Re: [patch] to gdb: portability fix: <sys/file.h>
Date: Tue, 06 Feb 2001 16:25:00 -0000
Message-id: <xnn1bzz6ex.fsf@greed.delorie.com>
References: <0102062301.AA24682@ivan.Harhan.ORG>
X-SW-Source: 2001-02/msg00093.html
Content-length: 2090

msokolov@ivan.Harhan.ORG (Michael Sokolov) writes:
> jtc@redback.com (J.T. Conklin) wrote:
> > I'm puzzled what you mean by the Cygnus tree.
> 
> Please don't pretend that you don't know.

The problem is that there is a *separate* repository inside Cygnus
(now Red Hat), which is *the* "cygnus tree" (now the "Red Hat tree" I
guess).  The repository on sources.redhat.com is *not* the "cygnus
tree".  It is the FSF's respository.  Since you are so adamant about
people using the term "UNIX" exactly correctly, you must be prepared
to use other terms exactly correctly yourself.

> Only because you politically favor systems

Politics has nothing to do with it.  It's a technical decision.  If
50% of the supported platforms follow one convention, and the rest
each have their own convention, which should we consider the standard
to which gdb adheres, and which need emulations?  It doesn't matter
what the name is, or how official the standard is, whatever minimizes
the total effort is going to win, and everyone is just going to have
to compromise.

> For me true centerline UNIX == V7/4.3BSD,

We don't care what UNIX is.

> I would have no idea and no desire to learn

Then perhaps your platform should choose a different maintainer?  One
who has a desire to learn how to integrate their platform's needs with
the needs of the project?

> whether F_OK is supposed to be in unistd.h or in fcntl.h or wherever
> by your "standards".

POSIX.1 is a certified ANSI/ISO standard.  Is 4.3BSD ANSI/ISO
certified?  But, that's irrelevent anyway.  The maintainers decide
what makes the most sense to the project.  They don't arbitrarily pick
a standard and stick to it without care for the consequences, but even
if they did, there is little you can do about it besides write your
own debugger.

> But in the meantime I want gdb to build on 4.3BSD.

Go ahead.  We won't stop you from doing what you want on your own
machines.  If you want your platform supported in the official
sources, you'll have to cooperate and compromise, just like everyone
else.  Oh, and being polite won't hurt either.
From ac131313@cygnus.com Tue Feb 06 16:59:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: Michael Sokolov <msokolov@ivan.Harhan.ORG>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [patch] to gdb: portability fix: <sys/file.h>
Date: Tue, 06 Feb 2001 16:59:00 -0000
Message-id: <3A809D19.76F586C3@cygnus.com>
References: <0102062301.AA24682@ivan.Harhan.ORG>
X-SW-Source: 2001-02/msg00094.html
Content-length: 406

Michael Sokolov wrote:
> > I'm puzzled what you mean by the Cygnus tree.

> Please don't pretend that you don't know. I know all about your conspiracy.

Hmm, I'd better let you in on a secret.  Part of the evil plan is to
merge GCC into the combined GDB + BINUTILS + DEJAGNU tree and thus
create a unified FSF compiler tools tree and put it all on
{gdb,gcc}.gnu.org.

Just don't tell anyone this.

	Andrew
From dj@redhat.com Tue Feb 06 17:06:00 2001
From: DJ Delorie <dj@redhat.com>
To: bje@redhat.com
Cc: binutils@sources.redhat.com, gdb-patches@sources.redhat.com
Subject: Re: Cosmetic change to src/configure
Date: Tue, 06 Feb 2001 17:06:00 -0000
Message-id: <200102070105.UAA26349@greed.delorie.com>
References: <200101310133.f0V1XQb23172@scooby.cygnus.com>
X-SW-Source: 2001-02/msg00095.html
Content-length: 241

> The following change tidies up `configure' so that an informative
> error is sent to stdout instead of stderr.  I often divert `configure'
> output to /dev/null, where this output should go as well.
> 
> Please commit if okay.

Committed.
From dj@redhat.com Tue Feb 06 17:15:00 2001
From: DJ Delorie <dj@redhat.com>
To: gdb-patches@sources.redhat.com, cgen@sources.redhat.com
Subject: [patch] i960-desc.c macros
Date: Tue, 06 Feb 2001 17:15:00 -0000
Message-id: <200102070114.UAA11647@greed.delorie.com>
X-SW-Source: 2001-02/msg00096.html
Content-length: 3282

Checking this in with fche's approval.  I didn't regenerate the file
because the i960 sim won't work with the current cgen, but without
this macro change (which is what cgen would have put in if
regenerating did work) the sim won't build with the latest gcc.

2001-02-06  DJ Delorie  <dj@redhat.com>

	* i960-desc.c: Update all the A macro definitions to the new
	stdc-sensitive versions that cgen would have used.

Index: i960-desc.c
===================================================================
RCS file: /cvs/src/src/sim/i960/i960-desc.c,v
retrieving revision 1.1.1.3
diff -p -2 -r1.1.1.3 i960-desc.c
*** i960-desc.c	1999/05/05 14:45:45	1.1.1.3
--- i960-desc.c	2001/02/07 01:12:47
***************
*** 3,7 ****
  THIS FILE IS MACHINE GENERATED WITH CGEN.
  
! Copyright (C) 1996, 1997, 1998, 1999 Free Software Foundation, Inc.
  
  This file is part of the GNU Binutils and/or GDB, the GNU debugger.
--- 3,7 ----
  THIS FILE IS MACHINE GENERATED WITH CGEN.
  
! Copyright (C) 1996, 1997, 1998, 1999, 2001 Free Software Foundation, Inc.
  
  This file is part of the GNU Binutils and/or GDB, the GNU debugger.
*************** CGEN_KEYWORD i960_cgen_opval_h_cc =
*** 185,189 ****
  /* The hardware table.  */
  
! #define A(a) (1 << CONCAT2 (CGEN_HW_,a))
  
  const CGEN_HW_ENTRY i960_cgen_hw_table[] =
--- 185,193 ----
  /* The hardware table.  */
  
! #if defined (__STDC__) || defined (ALMOST_STDC) || defined (HAVE_STRINGIZE)
! #define A(a) (1 << CGEN_HW_##a)
! #else
! #define A(a) (1 << CGEN_HW_/**/a)
! #endif
  
  const CGEN_HW_ENTRY i960_cgen_hw_table[] =
*************** const CGEN_HW_ENTRY i960_cgen_hw_table[]
*** 204,208 ****
  /* The instruction field table.  */
  
! #define A(a) (1 << CONCAT2 (CGEN_IFLD_,a))
  
  const CGEN_IFLD i960_cgen_ifld_table[] =
--- 208,216 ----
  /* The instruction field table.  */
  
! #if defined (__STDC__) || defined (ALMOST_STDC) || defined (HAVE_STRINGIZE)
! #define A(a) (1 << CGEN_IFLD_##a)
! #else
! #define A(a) (1 << CGEN_IFLD_/**/a)
! #endif
  
  const CGEN_IFLD i960_cgen_ifld_table[] =
*************** const CGEN_IFLD i960_cgen_ifld_table[] =
*** 241,246 ****
  /* The operand table.  */
  
! #define A(a) (1 << CONCAT2 (CGEN_OPERAND_,a))
! #define OPERAND(op) CONCAT2 (I960_OPERAND_,op)
  
  const CGEN_OPERAND i960_cgen_operand_table[] =
--- 249,262 ----
  /* The operand table.  */
  
! #if defined (__STDC__) || defined (ALMOST_STDC) || defined (HAVE_STRINGIZE)
! #define A(a) (1 << CGEN_OPERAND_##a)
! #else
! #define A(a) (1 << CGEN_OPERAND_/**/a)
! #endif
! #if defined (__STDC__) || defined (ALMOST_STDC) || defined (HAVE_STRINGIZE)
! #define OPERAND(op) I960_OPERAND_##op
! #else
! #define OPERAND(op) I960_OPERAND_/**/op
! #endif
  
  const CGEN_OPERAND i960_cgen_operand_table[] =
*************** const CGEN_OPERAND i960_cgen_operand_tab
*** 302,307 ****
  #undef A
  
- #define A(a) (1 << CONCAT2 (CGEN_INSN_,a))
  #define OP(field) CGEN_SYNTAX_MAKE_FIELD (OPERAND (field))
  
  /* The instruction table.  */
--- 318,327 ----
  #undef A
  
  #define OP(field) CGEN_SYNTAX_MAKE_FIELD (OPERAND (field))
+ #if defined (__STDC__) || defined (ALMOST_STDC) || defined (HAVE_STRINGIZE)
+ #define A(a) (1 << CGEN_INSN_##a)
+ #else
+ #define A(a) (1 << CGEN_INSN_/**/a)
+ #endif
  
  /* The instruction table.  */
From msokolov@ivan.Harhan.ORG Tue Feb 06 17:21:00 2001
From: msokolov@ivan.Harhan.ORG (Michael Sokolov)
To: gdb-patches@sources.redhat.com
Subject: Re: [patch] to gdb: portability fix: <sys/file.h>
Date: Tue, 06 Feb 2001 17:21:00 -0000
Message-id: <0102070118.AA25143@ivan.Harhan.ORG>
X-SW-Source: 2001-02/msg00097.html
Content-length: 1038

Andrew Cagney <ac131313@cygnus.com> wrote:

> Hmm, I'd better let you in on a secret.  Part of the evil plan is to
> merge GCC into the combined GDB + BINUTILS + DEJAGNU tree [...]

If you mean merging GCC into the *existing* repository in
sources.redhat.com:/cvs/src *as it is now* (which I will always call the Cygnus
tree and not the FSF tree because I care very much about the non-FSF Cygnus
modules like Newlib, Insight, Cygwin, etc), that would be great. That won't be
an evil plan, but a gorgeous plan, and that's what I have always been calling
for.

But...

> [...] and thus
> create a unified FSF compiler tools tree and put it all on
                   ^^^
> {gdb,gcc}.gnu.org.
  ^^^^^^^^^^^^^^^^^^

It would definitely be bad if it were all FSF/GNU-ised. I want a Cygnus tree,
not an FSF/GNU one.

-- 
Michael Sokolov
Public Service Agent
International Engineering and Science Task Force

1351 VINE AVE APT 27		Phone: +1-714-738-5409
FULLERTON CA 92833-4291 USA	(home office)

E-mail: msokolov@ivan.Harhan.ORG (ARPA TCP/SMTP)
From ac131313@cygnus.com Tue Feb 06 17:51:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: DJ Delorie <dj@redhat.com>, "Frank Ch. Eigler" <fche@cygnus.com>
Cc: gdb-patches@sources.redhat.com, cgen@sources.redhat.com
Subject: Re: [patch] i960-desc.c macros
Date: Tue, 06 Feb 2001 17:51:00 -0000
Message-id: <3A80A935.9FDEF5EA@cygnus.com>
References: <200102070114.UAA11647@greed.delorie.com>
X-SW-Source: 2001-02/msg00098.html
Content-length: 374

DJ, Frank,

> Checking this in with fche's approval.  I didn't regenerate the file
> because the i960 sim won't work with the current cgen, but without
> this macro change (which is what cgen would have put in if
> regenerating did work) the sim won't build with the latest gcc.

This concerns me.  It means that it isn't possible to re-build the i960
from source.

	Andrew
From dj@redhat.com Tue Feb 06 17:54:00 2001
From: DJ Delorie <dj@redhat.com>
To: ac131313@cygnus.com
Cc: fche@cygnus.com, gdb-patches@sources.redhat.com, cgen@sources.redhat.com
Subject: Re: [patch] i960-desc.c macros
Date: Tue, 06 Feb 2001 17:54:00 -0000
Message-id: <200102070153.UAA10384@greed.delorie.com>
References: <200102070114.UAA11647@greed.delorie.com> <3A80A935.9FDEF5EA@cygnus.com>
X-SW-Source: 2001-02/msg00099.html
Content-length: 342

> This concerns me.

Yup.  But without a suitable volunteer, bit rot is inevitable.

> It means that it isn't possible to re-build the i960 from source.

It builds fine from cvs, provided you *don't* use "--enable-cgen-maint".

If you regenerate the generated files, it miscompiles - it uses "insn"
all over the place but nobody declares it.
From ac131313@cygnus.com Tue Feb 06 19:01:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: Re: [rfc] Add set_gdbarch_data() and revamp
Date: Tue, 06 Feb 2001 19:01:00 -0000
Message-id: <3A80B98F.AAF33AAC@cygnus.com>
References: <3A79156A.5DD5C7E1@cygnus.com>
X-SW-Source: 2001-02/msg00100.html
Content-length: 806

FYI,

I've checked this in.

	Andrew
Wed Jan 31 09:58:18 2001  Andrew Cagney  <cagney@redhat.com>

        * gdbarch.sh: Include "gdb_assert.h".
        (struct gdbarch): Change ``nr_data'' to unsigned.
        (alloc_gdbarch_data, free_gdbarch_data): New functions.
        (gdbarch_free): Free the data-pointer vector.  Use xfree to
delete
        architecture vector.
        (struct gdbarch_data, struct gdbarch_data_registration): Move
init
        method to gdbarch_data.  Add free method, make index unsigned.
        (struct gdbarch_data_registry): Make nr unsigned.
        (register_gdbarch_data): Add free parameter. Store in
        gdbarch_data.
        (init_gdbarch_data): Use set_gdbarch_data.
        (set_gdbarch_data): New function.
        
        * gdbarch.h, gdbarch.c: Re-generate.
From ac131313@cygnus.com Tue Feb 06 19:41:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: Re: [rfc] Fix some nasty casts
Date: Tue, 06 Feb 2001 19:41:00 -0000
Message-id: <3A80C2EB.4C90A86B@cygnus.com>
References: <3A79AB96.E255247C@cygnus.com>
X-SW-Source: 2001-02/msg00101.html
Content-length: 405

Andrew Cagney wrote:

> Thu Feb  1 00:29:42 2001  Andrew Cagney  <cagney@redhat.com>
> 
>         * sol-thread.c (restore_inferior_pid): Save the PID in a freshly
>         allocated buffer.
>         (save_inferior_pid): Restore the PID from that tempoary
>         buffer. Delete the buffer.
>         * utils.c (make_cleanup_close, do_close_cleanup): Ditto for FD.

FYI, I've checked this in.

	Andrew
From ac131313@cygnus.com Tue Feb 06 19:47:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: Michael Elizabeth Chastain <chastain@cygnus.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA] testsuite/gdb.c++/cplusfuncs.{exp,cc}: work with either g++ demangler
Date: Tue, 06 Feb 2001 19:47:00 -0000
Message-id: <3A80C44B.BB7FAED0@cygnus.com>
References: <200102051905.LAA32545@bosch.cygnus.com>
X-SW-Source: 2001-02/msg00102.html
Content-length: 715

Michael Elizabeth Chastain wrote:
> 
> After my patch, gdb.c++/cplusfuncs.exp contains the lines:
> 
>     # gdb-gnats bug gdb/19:
>     # "gdb v3 demangler fails on hairyfunc5 hairyfunc6 hairyfunc7"
>     print_addr_2 "hairyfunc5" "hairyfunc5(int (*(*)($dm_type_char_star))(long))"
>     print_addr_2 "hairyfunc6" "hairyfunc6(int (*(*)($dm_type_int_star))(long))"
>     print_addr_2 "hairyfunc7" "hairyfunc7(int (*(*)(int (*)(char *)))(long))"
> 
> The ChangeLog entry says that I added this note to gdb.c++/cplusfuncs.exp.
> In the ChangeLog I could say: "added note that ..." because of the ambiguity
> in saying "note that".

Ah, I did a mindless search for the comment but didn't see it.  Ok then
:-)

	Andrew
From msokolov@ivan.Harhan.ORG Tue Feb 06 20:03:00 2001
From: msokolov@ivan.Harhan.ORG (Michael Sokolov)
To: gdb-patches@sources.redhat.com
Subject: Re: [patch] to gdb: portability fix: <sys/file.h>
Date: Tue, 06 Feb 2001 20:03:00 -0000
Message-id: <0102070400.AA25441@ivan.Harhan.ORG>
X-SW-Source: 2001-02/msg00103.html
Content-length: 4611

DJ Delorie <dj@redhat.com> wrote:

> The problem is that there is a *separate* repository inside Cygnus
> (now Red Hat), which is *the* "cygnus tree" (now the "Red Hat tree" I
> guess).

I know this very well, and *that* is the tree I really want to be working on if
I could, but I can't because it isn't free and I'm not affiliated with Red Hat.

I'm not working with FSF/GNU. I will never work with FSF/GNU because the GNU's
Not UNIX project is by definition working against UNIX, and UNIX is my personal
OS of choice. (It is also one of the official OSes of the IFCTF and IESTF, but
in this case it doesn't matter as much as UNIX being my personal OS of choice
because my involvement with the embedded development toolchain is mostly
personal, I'm not really representing the IFCTF or IESTF official position
here.)

The only remote connection between me and any GNU projects is that I like the
Cygnus toolchain for embedded development, and it has some GNU-based components
in it, and generally follows the GNU coding standards even in the non-GNU
modules. While I don't appreciate Cygnus' decision to follow the GNU coding
standards as opposed to, say, the Berkeley ones, I really really like the
Cygnus toolchain for embedded development, and I'm in no position to rewrite
the whole thing. I compromise by having a separate partition on my machine (and
in my life) for embedded development, and I tolerate some GNU-ness there,
exactly as much as I need in order to work with the Cygnus toolchain.

Now if all I wanted was to *use* the Cygnus toolchain, i.e., passively use a
given static version of it, I would just pick up some Cygnus release from
somewhere and use it. However, I want to actively work on a tree that many
other qualified developers are working on. There are two such tree, the Red Hat
internal one, which has all the bright Red Hat engineers working on it, and the
public one on sources.redhat.com, which has all the FSF/GNU folks working on it
(I politically disagree with FSF/GNU, but there are still very good people
working on FSF/GNU projects). The former is definitely better, but it's non-
free and I'm not affiliated with Red Hat, so it isn't an option and I have to
settle for the latter.

> The repository on sources.redhat.com is *not* the "cygnus
> tree".  It is the FSF's respository.

sources.redhat.com:/cvs/src is not FSF's, it has some FSF projects in it, but
it also has non-FSF Cygnus modules like Newlib, Insight, Cygwin, etc.

> Then perhaps your platform should choose a different maintainer?  One
> who has a desire to learn how to integrate their platform's needs with
> the needs of the project?

Do you mean that someone else should maintain the Berkeley UNIX code or the
support for it in the Cygnus toolchain and the GNU parts of it? But either way,
that is extremely unlikely. In the former case, I volunteered to bring 4.3BSD
back from the ashes in 1998 after no one else did in 10 years, since UC
Berkeley dropped it in 1988. In the latter case, I'm sure you know that 4.3BSD
does not use any GNU tools natively. If someone uses 4.3BSD in this millennium,
he/she certainly does so very conscientiously for political or religious
reasons, and all people using 4.3BSD today (whom I know as I lead the dev team
and we have a mailing list) feel the same way about FSF/GNU as I do. I
volunteered to maintain 4.3BSD host support in the Cygnus toolchain and its GNU
parts only because I like the Cygnus toolchain for embedded development. The
chances of someone else both using 4.3BSD and doing some embedded development
using the Cygnus toolchain are vanishingly small.

Oh, I do care very much about the needs of Cygnus toolchain overall (I assume
that's what you meant by "the project"), as I use it for embedded development,
and I want a good embedded development toolchain, not a crappy one.

> If you want your platform supported in the official
> sources, you'll have to cooperate and compromise, just like everyone
> else.

And I do that. My little patch does the same thing I've seen in a ton of places
elsewhere in the tree, and I don't see how it tries to make gdb conform to the
V7/4.3BSD way of doing things. I do cooperate and compromise. (I'm always
disappointed when people use memcpy/memmove instead of bcopy, for example, I
want it exactly the other way around, but I don't bitch about it publicly on
these lists.)

-- 
Michael Sokolov
Public Service Agent
International Engineering and Science Task Force

1351 VINE AVE APT 27		Phone: +1-714-738-5409
FULLERTON CA 92833-4291 USA	(home office)

E-mail: msokolov@ivan.Harhan.ORG (ARPA TCP/SMTP)
From kettenis@wins.uva.nl Tue Feb 06 23:37:00 2001
From: Mark Kettenis <kettenis@wins.uva.nl>
To: gdb-patches@sources.redhat.com
Subject: [PATCH] Remove duplicate #include <signal.h>
Date: Tue, 06 Feb 2001 23:37:00 -0000
Message-id: <200102070737.f177b8604404@delius.kettenis.local>
X-SW-Source: 2001-02/msg00104.html
Content-length: 723

I really love this new "Obvious Fix Rule".

Anyway, after J.T.'s signals.h removal patch event-top.c included
signal.h twice.  The attached patch (checked in) removes this duplication.

Mark

Index: ChangeLog
from  Mark Kettenis  <kettenis@gnu.org>

	* event-top.c: Remove duplicate #include <signal.h>.

Index: event-top.c
===================================================================
RCS file: /cvs/src/src/gdb/event-top.c,v
retrieving revision 1.11
diff -u -p -r1.11 event-top.c
--- event-top.c 2001/02/06 04:17:03 1.11
+++ event-top.c 2001/02/07 07:26:50
@@ -35,8 +35,6 @@
 #include <readline/readline.h>
 #include <readline/history.h>
 
-#include <signal.h>
-
 /* readline defines this.  */
 #undef savestring
 
From kettenis@wins.uva.nl Wed Feb 07 00:01:00 2001
From: Mark Kettenis <kettenis@wins.uva.nl>
To: gdb-patches@sources.redhat.com
Cc: ezannoni@cygnus.com
Subject: [PATCH, RFA] Fix handle_stop_sig lossage
Date: Wed, 07 Feb 2001 00:01:00 -0000
Message-id: <200102070800.f1780px04634@delius.kettenis.local>
X-SW-Source: 2001-02/msg00105.html
Content-length: 1436

Hi,

The attached patch makes GDB build again on Solaris 2.6 and
FreeBSD/Alpha (and probably a couple of more systems).  The problem is
that the fragment that defines STOP_SIGNAL if SIGSTP is defined in
event-top.h can appear before <signal.h> is included, whereas a
similar fragment exists in top.c, where <signal.h> is explicitly
included.  This leads to undefined references to handle_stop_sig.  I
suspect the roblem was somehow introduced by the recent signals.h
removal patch.

OK to check in the attached fix?

Mark


Index: ChangeLog
from  Mark Kettenis  <kettenis@gnu.org>
	* event-top.h [!STOP_SIGNAL]: #include <signal.h>.

Index: event-top.h
===================================================================
RCS file: /cvs/src/src/gdb/event-top.h,v
retrieving revision 1.1.1.3
diff -u -p -r1.1.1.3 event-top.h
--- event-top.h 1999/10/05 23:08:12 1.1.1.3
+++ event-top.h 2001/02/07 07:46:42
@@ -1,5 +1,5 @@
 /* Definitions used by GDB event-top.c.
-   Copyright 1999 Free Software Foundation, Inc.
+   Copyright 1999, 2001 Free Software Foundation, Inc.
    Written by Elena Zannoni <ezannoni@cygnus.com> of Cygnus Solutions.
 
    This file is part of GDB.
@@ -78,6 +78,7 @@ extern void set_async_prompt (char *args
 
 /* Signal to catch ^Z typed while reading a command: SIGTSTP or SIGCONT.  */
 #ifndef STOP_SIGNAL
+#include <signal.h>
 #ifdef SIGTSTP
 #define STOP_SIGNAL SIGTSTP
 extern void handle_stop_sig (int sig);
From eliz@is.elta.co.il Wed Feb 07 03:44:00 2001
From: Eli Zaretskii <eliz@is.elta.co.il>
To: "J.T. Conklin" <jtc@redback.com>
Cc: Michael Sokolov <msokolov@ivan.Harhan.ORG>, gdb-patches@sources.redhat.com
Subject: Re: [patch] to gdb: portability fix: <sys/file.h>
Date: Wed, 07 Feb 2001 03:44:00 -0000
Message-id: <Pine.SUN.3.91.1010207134037.4599E-100000@is>
References: <5melxbsdmd.fsf@jtc.redback.com>
X-SW-Source: 2001-02/msg00106.html
Content-length: 397

On 6 Feb 2001, J.T. Conklin wrote:

> We could
> create a gdb_unistd.h that simply includes unistd.h on systems that
> have that header, but defines the missing bits on others.

I like this solution better, especially since (AFAIK) Posix says F_OK 
and friends should be in unistd.h.

> Note this isn't a patch rejection.

Neither is the above.

> I'm not in a position to do that.

Neither am I.
From eliz@is.elta.co.il Wed Feb 07 03:48:00 2001
From: Eli Zaretskii <eliz@is.elta.co.il>
To: Michael Sokolov <msokolov@ivan.Harhan.ORG>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [patch] to gdb: portability fix: <sys/file.h>
Date: Wed, 07 Feb 2001 03:48:00 -0000
Message-id: <Pine.SUN.3.91.1010207134256.4599F-100000@is>
References: <0102062150.AA24428@ivan.Harhan.ORG>
X-SW-Source: 2001-02/msg00107.html
Content-length: 1128

On Tue, 6 Feb 2001, Michael Sokolov wrote:

> Anyone needing a define that's in different places on different systems should
> have logic to include different headers depending on config.h definitions. This
> is how it's done in the rest of the Cygnus tree.

F_OK and friends are Posix constant.  IIRC, the usual policy of GNU 
projects is to assume Posix compliance, and provide special solutions for 
non-Posix platforms whose support is deemed important.

In other words, Posix platforms should not be forced in yet another 
Autoconf test if we can avoid that.  IMHO, of course.

> > We could
> > create a gdb_unistd.h that simply includes unistd.h on systems that
> > have that header, but defines the missing bits on others.  We could
> > fix up those other gdb configs at the same time.
> 
> But this is not a problem of a specific header file being broken that can be
> wrappered around, it's just that the definitions of access(2) macros are in
> different headers on different systems.

It's a problem of a specific header that should have F_OK but doesn't.  
In my book, this is one definition of ``a broken header''.
From eliz@is.elta.co.il Wed Feb 07 03:57:00 2001
From: Eli Zaretskii <eliz@is.elta.co.il>
To: Michael Sokolov <msokolov@ivan.Harhan.ORG>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [patch] to gdb: portability fix: <sys/file.h>
Date: Wed, 07 Feb 2001 03:57:00 -0000
Message-id: <Pine.SUN.3.91.1010207134634.4599G-100000@is>
References: <0102062301.AA24682@ivan.Harhan.ORG>
X-SW-Source: 2001-02/msg00108.html
Content-length: 1122

On Tue, 6 Feb 2001, Michael Sokolov wrote:

> Then why have many gdb_*.h files rather than one system.h file? How would this
> goo be divided between different gdb_*.h files? Why should the F_OK logic be in
> gdb_unistd.h and not gdb_sys_file.h?

Because F_OK belongs to unistd.h according to Posix.

> If that's the route you want to take, someone else will have to do the work, as
> I won't be qualified for this.

I think you exaggerate the amount of work to some degree.  Until now, all 
the systems supported by GDB were able to build GDB, which means that they 
all define F_OK in the headers that are already included.  I will not be 
surprised to learn that they all define F_OK in unistd.h.  If that's 
true, all we need to do is to create gdb_unistd.h that does something 
like this (untested):

  #if HAVE_UNISTD_H
  #include <unistd.h>
  #endif

  #ifndef F_OK
  # if HAVE_SYS_FILE_H
  /* 4.3BSD has F_OK in sys/file.h.  */
  #  include <sys/file.h>
  # endif
  # ifndef F_OK
  #  define F_OK 0
  # endif
  #endif

Or something along these lines.  It is hardly worth starting a political
flame war over this. 
From eliz@is.elta.co.il Wed Feb 07 04:03:00 2001
From: Eli Zaretskii <eliz@is.elta.co.il>
To: Michael Sokolov <msokolov@ivan.Harhan.ORG>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [patch] to gdb: portability fix: <sys/file.h>
Date: Wed, 07 Feb 2001 04:03:00 -0000
Message-id: <Pine.SUN.3.91.1010207135521.4599H-100000@is>
References: <0102070400.AA25441@ivan.Harhan.ORG>
X-SW-Source: 2001-02/msg00109.html
Content-length: 671

On Tue, 6 Feb 2001, Michael Sokolov wrote:

> I'm not working with FSF/GNU. I will never work with FSF/GNU

Then don't.  It's your privilege.  This is what Free Software is all about.

But please do not mix political motivation with technical issues.  The
objections raised by DJ and J.T. were purely technical, not political.  
Let's remain on the technical level, please.  Let's try to cooperate so 
that we could move towards the same common goal: making GDB better.  
Please assume that whatever considerations you read in this thread (and 
elsewhere) are dictated by technical reasons.  From my experience with
people in this forum, this is a very sound assumption.
From fnasser@cygnus.com Wed Feb 07 09:01:00 2001
From: Fernando Nasser <fnasser@cygnus.com>
To: gdb-patches@sources.redhat.com, Keith Seitz <keiths@cygnus.com>, "Martin M. Hunt" <hunt@redhat.com>, Andrew Cagney <cagney@cygnus.com>
Subject: Write after approval additions
Date: Wed, 07 Feb 2001 09:01:00 -0000
Message-id: <3A817F5F.2B57D56E@cygnus.com>
X-SW-Source: 2001-02/msg00110.html
Content-length: 586

Andrew,

Keith Seitz and Martin Hunt are two of the people who developed the second generation of gdbtk (a.k.a. Insight).
They have worked on GDB as well for some years (their names
are all around old ChangeLog files).

I feel sort of weird having to check-in their patches.  Is it possible to add them to the list of "write after
approval" so they can do the check-in themselves?

Thanks,
Fernando

P.S.: Yes, they have valid assignments.

-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9
From ac131313@cygnus.com Wed Feb 07 10:32:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: [patch] Fix a remote-sim printf fmt, mn10300 buildable
Date: Wed, 07 Feb 2001 10:32:00 -0000
Message-id: <3A8193F3.358F12EC@cygnus.com>
X-SW-Source: 2001-02/msg00111.html
Content-length: 1737

FYI,

The attatched fixes a printf problem in remote.c (it simplifies the code
a little).  I've also managed to build mn10300-elf target.

	Andrew
2001-02-07  Andrew Cagney  <ac131313@redhat.com>

	* remote-sim.c (dump_mem): Cleanup printf format argument.
	* MAINTAINERS: Update, mn10300-elf now builds.

Index: MAINTAINERS
===================================================================
RCS file: /cvs/src/src/gdb/MAINTAINERS,v
retrieving revision 1.68
diff -p -r1.68 MAINTAINERS
*** MAINTAINERS	2001/02/07 03:11:44	1.68
--- MAINTAINERS	2001/02/07 17:54:40
*************** maintainer works with the native maintai
*** 112,118 ****
  	mn10200		(--target=mn10200-elf broken)
  			Maintenance only
  
! 	mn10300		(--target=mn10300-elf broken)
  			Andrew Cagney		cagney@cygnus.com
  
  	ns32k		(--target=ns32k-netbsd broken)
--- 112,118 ----
  	mn10200		(--target=mn10200-elf broken)
  			Maintenance only
  
! 	mn10300		--target=mn10300-elf ,-Werror
  			Andrew Cagney		cagney@cygnus.com
  
  	ns32k		(--target=ns32k-netbsd broken)
Index: remote-sim.c
===================================================================
RCS file: /cvs/src/src/gdb/remote-sim.c,v
retrieving revision 1.10
diff -p -r1.10 remote-sim.c
*** remote-sim.c	2001/02/02 19:14:33	1.10
--- remote-sim.c	2001/02/07 17:54:40
*************** dump_mem (char *buf, int len)
*** 129,135 ****
  	  long l[2];
  	  memcpy (l, buf, len);
  	  printf_filtered ("\t0x%lx", l[0]);
! 	  printf_filtered (len == 8 ? " 0x%x\n" : "\n", l[1]);
  	}
        else
  	{
--- 129,137 ----
  	  long l[2];
  	  memcpy (l, buf, len);
  	  printf_filtered ("\t0x%lx", l[0]);
! 	  if (len == 8)
! 	    printf_filtered (" 0x%lx", l[1]);
! 	  printf_filtered ("\n");
  	}
        else
  	{
From spolk@redhat.com Wed Feb 07 10:45:00 2001
From: Syd Polk <spolk@redhat.com>
To: Fernando Nasser <fnasser@cygnus.com>, gdb-patches@sources.redhat.com, Keith Seitz <keiths@cygnus.com>, "Martin M. Hunt" <hunt@redhat.com>, Andrew Cagney <cagney@cygnus.com>
Subject: Re: Write after approval additions
Date: Wed, 07 Feb 2001 10:45:00 -0000
Message-id: <4.2.0.58.20010207104435.01a7e9a0@pop.cygnus.com>
References: <3A817F5F.2B57D56E@cygnus.com>
X-SW-Source: 2001-02/msg00112.html
Content-length: 666

At 12:01 PM 2/7/01 -0500, Fernando Nasser wrote:
>Andrew,
>
>Keith Seitz and Martin Hunt are two of the people who developed the second 
>generation of gdbtk (a.k.a. Insight).
>They have worked on GDB as well for some years (their names
>are all around old ChangeLog files).
>
>I feel sort of weird having to check-in their patches.  Is it possible to 
>add them to the list of "write after
>approval" so they can do the check-in themselves?
>
>Thanks,
>Fernando
>
>P.S.: Yes, they have valid assignments.

As one of the maintainers of Insight, I would love to see this happen.


Syd Polk		spolk@redhat.com
Engineering Manager	+1 415 777 9810 x 241
Red Hat, Inc.