From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eli Zaretskii To: jtc@redback.com Cc: ac131313@cygnus.com, fpastor.etra-id@etra.es, gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH]: Fix ser-go32.c for UARTs with FIFOs. Date: Tue, 06 Feb 2001 12:39:00 -0000 Message-id: <200102062038.PAA15759@indy.delorie.com> References: <3A7F6BCF.605B1D7F@cygnus.com> <6137-Tue06Feb2001105337+0200-eliz@is.elta.co.il> <004f01c09034$e7aa2300$0500a8c0@etra.es> <3A804C5F.9F2B6D84@cygnus.com> <5mitmnsik8.fsf@jtc.redback.com> X-SW-Source: 2001-02/msg00085.html > 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: 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 , where this constant is defined on 4.3BSD. The patch below makes it include 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 * configure.in (AC_CHECK_HEADERS): Add sys/file.h. * configure, config.in: Regenerate. * corelow.c: Include 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 #include #include + #ifdef HAVE_SYS_FILE_H + #include + #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 * 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: 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 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 , where this constant is defined Michael> on 4.3BSD. The patch below makes it include 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 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: 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: 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 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: 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 over those with this define in ? 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 To: gdb-patches@sources.redhat.com Cc: msokolov@ivan.Harhan.ORG (Michael Sokolov) Subject: Re: [patch] to gdb: portability fix: Date: Tue, 06 Feb 2001 16:25:00 -0000 Message-id: 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 To: Michael Sokolov Cc: gdb-patches@sources.redhat.com Subject: Re: [patch] to gdb: portability fix: 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 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 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 * 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: 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 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 To: DJ Delorie , "Frank Ch. Eigler" 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 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 To: GDB Patches 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 * 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 To: GDB Patches 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 > > * 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 To: Michael Elizabeth Chastain 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: 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 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 To: gdb-patches@sources.redhat.com Subject: [PATCH] Remove duplicate #include 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 * event-top.c: Remove duplicate #include . 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 #include -#include - /* readline defines this. */ #undef savestring >From kettenis@wins.uva.nl Wed Feb 07 00:01:00 2001 From: Mark Kettenis 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 is included, whereas a similar fragment exists in top.c, where 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 * event-top.h [!STOP_SIGNAL]: #include . 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 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 #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 To: "J.T. Conklin" Cc: Michael Sokolov , gdb-patches@sources.redhat.com Subject: Re: [patch] to gdb: portability fix: Date: Wed, 07 Feb 2001 03:44:00 -0000 Message-id: 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 To: Michael Sokolov Cc: gdb-patches@sources.redhat.com Subject: Re: [patch] to gdb: portability fix: Date: Wed, 07 Feb 2001 03:48:00 -0000 Message-id: 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 To: Michael Sokolov Cc: gdb-patches@sources.redhat.com Subject: Re: [patch] to gdb: portability fix: Date: Wed, 07 Feb 2001 03:57:00 -0000 Message-id: 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 #endif #ifndef F_OK # if HAVE_SYS_FILE_H /* 4.3BSD has F_OK in sys/file.h. */ # include # 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 To: Michael Sokolov Cc: gdb-patches@sources.redhat.com Subject: Re: [patch] to gdb: portability fix: Date: Wed, 07 Feb 2001 04:03:00 -0000 Message-id: 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 To: gdb-patches@sources.redhat.com, Keith Seitz , "Martin M. Hunt" , Andrew Cagney 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 To: GDB Patches 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 * 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 To: Fernando Nasser , gdb-patches@sources.redhat.com, Keith Seitz , "Martin M. Hunt" , Andrew Cagney 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.