Re: Linux sigtramp detection code moved to its proper place

[Mark Kettenis <kettenis@wins.uva.nl>]

   Date: Sat, 18 Mar 2000 17:27:44 -0500 (EST)
   From: Eli Zaretskii <eliz@delorie.com>

   > *** gdb/Makefile.in	2000/03/16 10:23:38	1.13
   > --- gdb/Makefile.in	2000/03/17 19:59:40
   > ***************
   > *** 1063,1068 ****
   > --- 1063,1069 ----
   >   	i386-tdep.c i386b-nat.c i386mach-nat.c i386v-nat.c i386-linux-nat.c \
   >   	i386aix-nat.c i386m3-nat.c i386v4-nat.c i386ly-tdep.c \
   >   	i387-tdep.c \
   > + 	i386-linux-tdep.c \
   >   	i960-tdep.c \
   >   	infptrace.c inftarg.c irix4-nat.c irix5-nat.c isi-xdep.c \
   >   	lynx-nat.c m3-nat.c \

   I see you already added the new file.  Sigh...  Is it possible to find
   a different name for it, one which won't clash with i386-linux-nat.c?
   How about i386linux-tdep.c, for example?

Yuck, that's ugly!

Is it really important that these Linux-specific files are correctly
extracted on MS-DOS?  I believe your argument was about buggy tar
programs floating around, but I don't think it is too much too ask
people to fix their tar before trying to build GDB.

Mark
From fnasser@cygnus.com Sat Apr 01 00:00:00 2000
From: Fernando Nasser <fnasser@cygnus.com>
To: jtc@redback.com
Cc: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: Re: Deprecating commands; Was: RFC: patch for ...
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38AAFCB4.EFC20163@cygnus.com>
References: <38AA23AF.34D2C08B@cygnus.com> <38AAE434.E3B21500@cygnus.com> <5memad2bsw.fsf@jtc.redbacknetworks.com>
X-SW-Source: 2000-q1/msg00200.html
Content-length: 1745

"J.T. Conklin" wrote:
> 
> >>>>> "Fernando" == Fernando Nasser <fnasser@cygnus.com> writes:
> Fernando> Talking about "bad" commands, what can be worse that the
> Fernando> "set" overloading?  It should only work for gdb control
> Fernando> switches.  The "set var" should be name "assign".  But who
> Fernando> dares to change this after 15+ years...
> 
> If we were to have a different command for setting variables, I'd pick
> "write" over "assign".  However I see this in much the same way as the
> BASIC "LET" keyword --- a useless bit of syntactic sugar.  I'd prefer
> being able to set program variables directly:
> 
>         (gdb) print x
>         $1 = 3
>         (gdb) x = 4
> 
Sure, but on the other hand not having the "set"/"let"/"assign"/"write"
or whatever keyord starts to impose restrictions on variable names.  You
end up with a reserved keyword list that is the union of all languages
supported by gdb.


> but I suspect that would require a major overhaul of the command
> parser.
> 
Yes, it probably would.


> Another issue is that "set" is used to assign convienence variables
> and GDB's internal variables.  I see some merit in actually merging
> these so that scripts can access the values.  There are some issues
> that may make it difficult to do.  For example, many set commands do
> extra error checking that simply setting a convienence variable would
> not; GBD's scripting language has only a global identifier namespace;
> etc.  Nevertheless, I'd love to be able to do this.
> 
Good points.



-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@cygnus.com
2323 Yonge Street, Suite #300           Tel:  416-482-2661 ext. 311
Toronto, Ontario   M4P 2C9              Fax:  416-482-6299
From eliz@delorie.com Sat Apr 01 00:00:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: kettenis@wins.uva.nl
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH]: DJGPP build and cleanup
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200002241118.GAA19392@indy.delorie.com>
References: <200002232229.RAA18809@indy.delorie.com> <200002232247.e1NMljJ28359@delius.kettenis.local>
X-SW-Source: 2000-q1/msg00357.html
Content-length: 2026

> From: Mark Kettenis <kettenis@wins.uva.nl>
>
>    Date: Wed, 23 Feb 2000 17:29:16 -0500 (EST)
>    From: Eli Zaretskii <eliz@delorie.com>
> 
>    The change to i386-tdep.c should probably be approved by someone (I
>    cannot figure out from MAINTAINERS who's responsible for i386
>    targets).
> 
> Youd didn't include the changes to i386-tdep.c :-(.

I erroneously appended them to the other set of patches I sent
yesterday.  I attach it below again.

> The point is that if you look at the GCC configuration files, you'll
> see that returning FP values in the FP registers is the default for
> most (probably all) i386 targets.  So I think this should be the
> default in GDB too.

I didn't know that this was the case, but if it is so, I agree that
returning FP values in registers should be the default.


2000-02-23  Eli Zaretskii  <eliz@is.elta.co.il>

	* i386-tdep.c (i386_extract_return_value)
	[I386_AIX_TARGET || I386_GNULINUX_TARGET]: Add I386_DJGPP_TARGET
	to the list of targets which return FP values in FP registers.

--- gdb/i386-tdep.c~0	Tue Oct 19 02:46:36 1999
+++ gdb/i386-tdep.c	Wed Feb 23 12:17:20 2000
@@ -702,9 +702,9 @@ i386_extract_return_value (type, regbuf,
      char regbuf[REGISTER_BYTES];
      char *valbuf;
 {
-  /* On AIX and i386 GNU/Linux, floating point values are returned in
-     floating point registers.  */
-#if defined(I386_AIX_TARGET) || defined(I386_GNULINUX_TARGET)
+  /* On AIX, i386 GNU/Linux and DJGPP, floating point values are
+     returned in floating point registers.  */
+#if defined(I386_AIX_TARGET) || defined(I386_GNULINUX_TARGET) || defined(I386_DJGPP_TARGET)
   if (TYPE_CODE_FLT == TYPE_CODE (type))
     {
       double d;
@@ -720,7 +720,7 @@ i386_extract_return_value (type, regbuf,
       store_floating (valbuf, TYPE_LENGTH (type), d);
     }
   else
-#endif /* I386_AIX_TARGET || I386_GNULINUX_TARGET*/
+#endif /* I386_AIX_TARGET || I386_GNULINUX_TARGET || I386_DJGPP_TARGET */
     {
 #if defined(LOW_RETURN_REGNUM)
       int len = TYPE_LENGTH (type);
From eliz@delorie.com Sat Apr 01 00:00:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: Peter.Schauer@regent.e-technik.tu-muenchen.de
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: RFA: breakpoint.c: Minor output fixes for hardware watchpoints
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003091337.IAA19948@indy.delorie.com>
References: <200003072114.WAA26280@reisser.regent.e-technik.tu-muenchen.de>
X-SW-Source: 2000-q1/msg00618.html
Content-length: 884

> During implementation of hardware watchpoints on Solaris, I noticed the
> following inconsistencies in breakpoint.c output between software and
> hardware breakpoints.

Both problems confirmed on x86 using the DJGPP native version.

Actually, these two problems were on my todo list since last summer,
but since they are merely annoyances, they got pushed back ;-).

> Here is a patch for both problems:
> 
> 2000-03-07  Peter Schauer  <pes@regent.e-technik.tu-muenchen.de>
> 
> 	* breakpoint.c (insert_breakpoints, do_enable_breakpoint):  Reselect
> 	the saved frame silently after frame selection for watchpoint
> 	evaluation.
> 	(insert_breakpoints):  Add missing space in `Hardware watchpoint
> 	deleted' message.  Do not reinsert hardware watchpoint if it is
> 	already marked for deletion at next stop.

Both problems are gone with these patches in the DJGPP version.
Thanks!
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Fernando Nasser <fnasser@cygnus.com>
Cc: Scott Bambrough <scottb@netwinder.org>, gdb-patches@sourceware.cygnus.com, jingham@cygnus.com
Subject: Re: Patch for arm_push_arguments
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38CEDC1A.7D997EF3@cygnus.com>
References: <38CE9C8B.3EC5B7F1@netwinder.org> <38CEA1FF.CEA9553@cygnus.com>
X-SW-Source: 2000-q1/msg00699.html
Content-length: 972

Fernando Nasser wrote:
> 
> Scott,
> 
> I have to try it on a few targets, so I need a few days.  I will try to run all the tests this week though.
> 
> Thanks for doing this.
> 
> Fernando
> 
> Scott Bambrough wrote:
> >
> > Hi guys,
> >
> >         * arm-tdep.c (arm_push_arguments): Correctly code for converting a
> >         float argument from host format to a target double when preparing the
> >         call frame for a function.
> >
> > This works for me.  Can you try it out.  If it works, let me know and I'll check
> > it in.
> >
> > Scott
> >

Scott,

To expand on what I suspect Fernando is doing, he probably has built a
``--target=arm-elf'' tool-chain (compiler, linker, debugger) and is then
testing it a dejagnu entry like:

    { "arm-*elf" } {
       set target_list "arm-sim/-mlittle-endian"
    }

(along with a few extra's for remote boards).  This checks both big and
little endian targets without any need to own real hardware.

	enjoy,
		Andrew
From msnyder@cygnus.com Sat Apr 01 00:00:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: dan@cgsoftware.com
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [RFA] Demangled minsym hash table broken
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38E2A65B.7C32@cygnus.com>
References: <pusd46y7.fsf@dan.resnet.rochester.edu>
X-SW-Source: 2000-q1/msg01116.html
Content-length: 186

Daniel Berlin wrote:

> So up until now, the demangled symbol table was never working, as i
> had suspected.

Well, that is, since the addition of the hash table
(I'm sure you meant)...
From kevinb@cygnus.com Sat Apr 01 00:00:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: shebs@apple.com
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH RFA] testsuite changes needed for AIX 4.3
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <1000216021706.ZM2429@ocotillo.lan>
References: <1000215230816.ZM2175@ocotillo.lan> <38A9E4F9.514007E1@apple.com> <shebs@apple.com>
X-SW-Source: 2000-q1/msg00165.html
Content-length: 1514

On Feb 15,  3:44pm, Stan Shebs wrote:

> Kevin Buettner wrote:
> > 
> > I hereby reqest approval for committing the following changes:
> > 
> >         * gdb.base/pointers.c (usevar): New function.
> >         (main): Make sure that global variables v_int_pointer2, rptr,
> >         and y are all referenced someplace in the program by calling
> >         usevar() on them.  [Some linkers delete symbols which are
> >         never referenced.  The space remains, but there's no way to
> >         get a (symbolic) handle on the variable from the debugger.]
> > 
> >         * gdb.base/scope.exp: For powerpc-*-*, xfail the same tests
> >         that rs6000-*-* does.
> 
> This looks reasonable to me, with the same question as Mark Kettenis
> raises: are the xfails unconditional because the tests fail whether
> xlc or gcc is used as the compiler?  If they pass with xlc, then you
> need to test gcc_compiled.

Okay.  As soon as I get the rest of my patches from the branch I was
working on merged in, I was going to do a build from sourceware.  I'll
test with xlc then.  (The machine that I had been working on didn't
have xlc on it, or if it did, I couldn't find it.)

Also, I'd appreciate it if someone could explain to me why these
xfails are necessary.  (I haven't looked hard at the problem; I
just noticed that these tests were xfailed for rs6000, and I was
getting FAILs on powerpc, so it seemed reasonable to xfail them
for powerpc too.)

Kevin

-- 
Kevin Buettner
kev@primenet.com, kevinb@redhat.com
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Jimmy Guo <guo@cup.hp.com>
Cc: Michael Snyder <msnyder@cygnus.com>, John David Anglin <dave@hiauly1.hia.nrc.ca>, gdb-patches@sourceware.cygnus.com
Subject: Re: Initialization of hpux_threads
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38D7F9C4.ECF7E17F@cygnus.com>
References: <Pine.LNX.4.10.10003211208350.31096-100000@hpcll168.cup.hp.com>
X-SW-Source: 2000-q1/msg00879.html
Content-length: 1706

Jimmy Guo wrote:
> 
> On Fri, 17 Mar 2000, Michael Snyder wrote:
> 
> >John David Anglin wrote:
> >>
> >> Thu Mar 16 16:49:27 EST 2000  John David Anglin  <dave@hiauly1.hia.nrc.ca>
> >>
> >>         * configure.in: Don't call _initialize_hpux_thread twice.
> >>         * configure: Regenerated.
> >>
> >> --- configure.in.orig   Mon Mar  6 18:30:12 2000
> >> +++ configure.in        Thu Mar 16 14:22:26 2000
> >> @@ -330,7 +330,6 @@
> >>              AC_DEFINE(HAVE_HPUX_THREAD_SUPPORT)
> >>              CONFIG_OBS="${CONFIG_OJS} hpux-thread.o"
> >>              CONFIG_SRCS="${CONFIG_SRCS} hpux-thread.c"
> >> -           CONFIG_INITS="${CONFIG_INITS} hpux-thread.c"
> >>           else
> >>              AC_MSG_RESULT(no (suppressed because you are not using GCC))
> >>           fi
> >
> >If someone from HP will approve this, I will check it in...
> >
> >                               Michael Snyder
> 
> This looks fine.  Just an observation:
> CONFIG_OBS is part of DEPFILES, which is part of COMMON_OBS, which is
> part of OBS, which is part of INITFILES.  It looks like all three usages
> of CONFIG_INITS in configure.in can be removed.  Maybe you can just
> remove CONFIG_INITS altogether in configure.in and Makefile.in.  Since
> OBS file list is already looked at by init.c rule, it really makes no
> sense to maintain a CONFIG_INITS file list.

No. CONFIG_INITS was added because things get complicated when adding
sub-directory files (eg MI) that contain _initialize_*() functions.  The
mistake was to assume that it was needed in all (rather than special)
cases.

By doing this the MI avoided the need to add any nasty initialization
hooks to main() - unlike tui, MPW, and GDBTK.

	Andrew
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Stan Shebs <shebs@apple.com>
Cc: Michael Snyder <msnyder@cygnus.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: gdb.texinfo broken?
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38D7FDD1.D54DE1D8@cygnus.com>
References: <38D6CF69.6844@cygnus.com> <200003211819.NAA12435@indy.delorie.com> <38D7C977.FA3@cygnus.com> <5mitygglxs.fsf@jtc.redbacknetworks.com>
X-SW-Source: 2000-q1/msg00882.html
Content-length: 325

"J.T. Conklin" wrote:

> It looks like the changes to the directory entry require the latest
> makeinfo.  I tried to use makeinfo from texinfo-3.2 and it failed,
> makeinfo from texinfo-4.0 works.

From memory, the possibility of requiring texinfo 4.0 as part of
building GDB 5 was considered and rejected :-(

oops,
	Andrew
From scottb@netwinder.org Sat Apr 01 00:00:00 2000
From: Scott Bambrough <scottb@netwinder.org>
To: Michael Snyder <msnyder@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: store_floating() and arm-tdep.c
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38C917C1.3E6E2C19@netwinder.org>
References: <1000229000345.ZM15006@ocotillo.lan> <38BCE46B.CD7889B5@cygnus.com> <1000302074643.ZM19182@ocotillo.lan> <38C7BF53.731F8CF6@redhat.com> <38C7C9A4.3566EC87@netwinder.org> <38C7F23D.61AF@cygnus.com>
X-SW-Source: 2000-q1/msg00642.html
Content-length: 1429

> Scott Bambrough wrote:
> >
> > I've been running tests on the ARM Linux target on a NetWinder regularly.  The
> > results of the testsuite follow.  Most of the problems are due to no
> > linuxthreads support and problems stepping in/out or backtracing in signal
> > handlers.  I'll work at implementing support for these over time.  I was hoping
> > to port the x86 work, but just haven't had the time.
> 
Michael Snyder wrote:
> 
> Hmm, the new thread_db module should be pretty
> target-independent (correct me if I'm wrong).

Ok.  I attempted to put the linuxthreads support in last night.  It was
relatively painless, but I have reached a stumbling block with glibc 2.1.2.  In
gdb_proc_service.h there are the following two definitions:

#ifndef HAVE_PRGREGSET_T
typedef gregset_t  prgregset_t;         /* BOGUS BOGUS BOGUS */
#endif

#ifndef HAVE_PRFPREGSET_T
typedef fpregset_t prfpregset_t;        /* BOGUS BOGUS BOGUS */
#endif

The BOGUS comments are accurate.  Neither gregset_t or fpregset_t are defined in
<sys/procfs.h>.  prgregset_t and prfpregset_t are also used in gdb_threads_db.h
as well without checking the defines from config.h.  I'm trying this on 2.1.3
ATM, but for the most part, the installed base of users is using 2.1.2 on ARM
Linux.  Any thoughts on how I could get around this?

Scott

-- 
Scott Bambrough - Software Engineer
REBEL.COM    http://www.rebel.com
NetWinder    http://www.netwinder.org
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: [PATCH] gdbarch cleanups part 1
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38E2E686.2227D8F9@cygnus.com>
X-SW-Source: 2000-q1/msg01122.html
Content-length: 5983

FYI,

I committed the attatched cleanups.

	Andrew
\x03
Thu Mar 30 12:09:50 2000  Andrew Cagney  <cagney@b1.cygnus.com>

	* gdbarch.h, gdbarch.c: Re-indent.  Remove FIXMEs.
	* gdbarch.sh: Re-sync with gdbarch.[hc].

Index: gdbarch.sh
===================================================================
RCS file: /cvs/src/src/gdb/gdbarch.sh,v
retrieving revision 1.5
diff -p -r1.5 gdbarch.sh
*** gdbarch.sh	2000/03/21 20:40:43	1.5
--- gdbarch.sh	2000/03/30 05:31:15
***************
*** 1,7 ****
  #!/usr/local/bin/bash
  
  # Architecture commands for GDB, the GNU debugger.
! # Copyright 1998-1999 Free Software Foundation, Inc.
  #
  # This file is part of GDB.
  #
--- 1,7 ----
  #!/usr/local/bin/bash
  
  # Architecture commands for GDB, the GNU debugger.
! # Copyright 1998-2000 Free Software Foundation, Inc.
  #
  # This file is part of GDB.
  #
***************
*** 19,24 ****
--- 19,40 ----
  # along with this program; if not, write to the Free Software
  # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
  
+ compare_new ()
+ {
+     file=$1
+     if ! test -r ${file}
+     then
+ 	echo "${file} missing? cp new-${file} ${file}" 1>&2
+     elif diff -c ${file} new-${file}
+     then
+ 	echo "${file} unchanged" 1>&2
+     else
+ 	echo "${file} has changed? cp new-${file} ${file}" 1>&2
+     fi
+ }
+ 
+ 
+ # Format of the input table
  read="class level macro returntype function formal actual attrib default init invalid_p fmt print print_p description"
  
  # dump out/verify the doco
*************** fi
*** 259,264 ****
--- 275,282 ----
  copyright ()
  {
  cat <<EOF
+ /* *INDENT-OFF* */ /* THIS FILE IS GENERATED */
+ 
  /* Dynamic architecture support for GDB, the GNU debugger.
     Copyright 1998-1999, Free Software Foundation, Inc.
  
*************** cat <<EOF
*** 279,286 ****
     Foundation, Inc., 59 Temple Place - Suite 330,
     Boston, MA 02111-1307, USA.  */
  
- /* *INDENT-OFF* */ /* \`\`typedef (f)();'' confuses indent */
- 
  /* This file was created with the aid of \`\`gdbarch.sh''.
  
     The bourn shell script \`\`gdbarch.sh'' creates the files
--- 297,302 ----
*************** extern void gdbarch_dump (void);
*** 742,756 ****
  EOF
  exec 1>&2
  #../move-if-change new-gdbarch.h gdbarch.h
! if ! test -r gdbarch.h
! then
!   echo "gdbarch.h missing? cp new-gdbarch.h gdbarch.h" 1>&2
! elif diff -c gdbarch.h new-gdbarch.h
! then
!   echo "gdbarch.h unchanged" 1>&2
! else
!   echo "gdbarch.h has changed? cp new-gdbarch.h gdbarch.h" 1>&2
! fi
  
  
  #
--- 758,764 ----
  EOF
  exec 1>&2
  #../move-if-change new-gdbarch.h gdbarch.h
! compare_new gdbarch.h
  
  
  #
*************** struct gdbarch_tdep *
*** 1076,1082 ****
  gdbarch_tdep (struct gdbarch *gdbarch)
  {
    if (gdbarch_debug >= 2)
-     /* FIXME: gdb_std??? */
      fprintf_unfiltered (gdb_stdlog, "gdbarch_tdep called\n");
    return gdbarch->tdep;
  }
--- 1084,1089 ----
*************** do
*** 1098,1104 ****
          echo "  if (gdbarch->${function} == 0)"
          echo "    internal_error (\"gdbarch: gdbarch_${function} invalid\");"
  	echo "  if (gdbarch_debug >= 2)"
- 	echo "    /* FIXME: gdb_std??? */"
  	echo "    fprintf_unfiltered (gdb_stdlog, \"gdbarch_${function} called\n\");"
          test "${actual}" = "-" && actual=""
         	if [ "${returntype}" = "void" ]
--- 1105,1110 ----
*************** do
*** 1131,1137 ****
  	  echo "    internal_error (\"gdbarch: gdbarch_${function} invalid\");"
  	fi
  	echo "  if (gdbarch_debug >= 2)"
- 	echo "    /* FIXME: gdb_std??? */"
  	echo "    fprintf_unfiltered (gdb_stdlog, \"gdbarch_${function} called\n\");"
  	echo "  return gdbarch->${function};"
  	echo "}"
--- 1137,1142 ----
*************** do
*** 1149,1155 ****
  	echo "gdbarch_${function} (struct gdbarch *gdbarch)"
  	echo "{"
  	echo "  if (gdbarch_debug >= 2)"
- 	echo "    /* FIXME: gdb_std??? */"
  	echo "    fprintf_unfiltered (gdb_stdlog, \"gdbarch_${function} called\n\");"
  	echo "  return gdbarch->${function};"
  	echo "}"
--- 1154,1159 ----
*************** extern void _initialize_gdbarch (void);
*** 1965,1970 ****
--- 1969,1976 ----
  void
  _initialize_gdbarch ()
  {
+   struct cmd_list_element *c;
+ 
    add_prefix_cmd ("endian", class_support, set_endian,
  		  "Set endianness of target.",
  		  &endianlist, "set endian ", 0, &setlist);
*************** _initialize_gdbarch ()
*** 1991,2015 ****
    tm_print_insn_info.memory_error_func = dis_asm_memory_error;
    tm_print_insn_info.print_address_func = dis_asm_print_address;
  
!   add_show_from_set (add_set_cmd ("archdebug",
  				  class_maintenance,
  				  var_zinteger,
  				  (char *)&gdbarch_debug,
  				  "Set architecture debugging.\n\\
! When non-zero, architecture debugging is enabled.", &setlist),
! 		     &showlist);
  }
  EOF
  
  # close things off
  exec 1>&2
  #../move-if-change new-gdbarch.c gdbarch.c
! if ! test -r gdbarch.c
! then
!   echo "gdbarch.c missing? cp new-gdbarch.c gdbarch.c" 1>&2
! elif diff -c gdbarch.c new-gdbarch.c
! then
!   echo "gdbarch.c unchanged" 1>&2
! else
!   echo "gdbarch.c has changed? cp new-gdbarch.c gdbarch.c" 1>&2
! fi
--- 1997,2022 ----
    tm_print_insn_info.memory_error_func = dis_asm_memory_error;
    tm_print_insn_info.print_address_func = dis_asm_print_address;
  
!   add_show_from_set (add_set_cmd ("arch",
  				  class_maintenance,
  				  var_zinteger,
  				  (char *)&gdbarch_debug,
  				  "Set architecture debugging.\n\\
! When non-zero, architecture debugging is enabled.", &setdebuglist),
! 		     &showdebuglist);
!   c = add_set_cmd ("archdebug",
! 		   class_maintenance,
! 		   var_zinteger,
! 		   (char *)&gdbarch_debug,
! 		   "Set architecture debugging.\n\\
! When non-zero, architecture debugging is enabled.", &setlist);
! 
!   deprecate_cmd (c, "set debug arch");
!   deprecate_cmd (add_show_from_set (c, &showlist), "show debug arch");
  }
  EOF
  
  # close things off
  exec 1>&2
  #../move-if-change new-gdbarch.c gdbarch.c
! compare_new gdbarch.c
From msnyder@cygnus.com Sat Apr 01 00:00:00 2000
From: msnyder@cygnus.com
To: gdb-patches@sourceware.cygnus.com
Cc: cagney@cygnus.com, fnasser@cygnus.com
Subject: [PATCH]: swat a warning in cli-out.c
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003240110.RAA21711@seadog.cygnus.com>
X-SW-Source: 2000-q1/msg00960.html
Content-length: 1137

This eliminates a warning on 64-bit solaris.

2000-03-23  Michael Snyder  <msnyder@seadog.cygnus.com>

        * cli-out.h: include gdb_string.h to avoid compiler warnings.

Index: ChangeLog
===================================================================
RCS file: /cvs/src/src/gdb/ChangeLog,v
retrieving revision 1.170
diff -c -r1.170 ChangeLog
*** ChangeLog	2000/03/23 23:43:19	1.170
--- ChangeLog	2000/03/24 01:08:15
***************
*** 1,3 ****
--- 1,7 ----
+ 2000-03-23  Michael Snyder  <msnyder@seadog.cygnus.com>
+ 
+ 	* cli-out.h: include gdb_string.h to avoid compiler warnings.
+ 
  2000-03-23  Fernando Nasser  <fnasser@cygnus.com>
  
  	From David Whedon <dwhedon@gordian.com>
Index: cli-out.c
===================================================================
RCS file: /cvs/src/src/gdb/cli-out.c,v
retrieving revision 1.2
diff -c -r1.2 cli-out.c
*** cli-out.c	2000/02/20 18:23:31	1.2
--- cli-out.c	2000/03/24 01:08:15
***************
*** 23,28 ****
--- 23,29 ----
  #include "defs.h"
  #include "ui-out.h"
  #include "cli-out.h"
+ #include "gdb_string.h"
  
  /* Convenience macro for allocting typesafe memory. */
  
From ezannoni@cygnus.com Sat Apr 01 00:00:00 2000
From: Elena Zannoni <ezannoni@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: PATCH corefiles reading on alpha-linux
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <14526.63171.337788.889969@kwikemart.cygnus.com>
X-SW-Source: 2000-q1/msg00461.html
Content-length: 1733

gdb/config/alpha/alpha-linux.mh lists core-regset.o as one of
the NATDEPFILES.
This causes _initialize_core_regset() to be called, and this in turn 
calls add_core_fns with bfd_target_elf_flavour.

Later on, _initialize_core_alpha() adds another core function
structure with the same flavour.  When a core file is loaded, this
causes a warning to be printed, because both function sets match the
expected bfd flavour.

I am going to check this in. OK?

Elena

Index: alpha-linux.mh
===================================================================
RCS file: /cvs/src/src/gdb/config/alpha/alpha-linux.mh,v
retrieving revision 1.1.1.3
diff -c -r1.1.1.3 alpha-linux.mh
*** alpha-linux.mh      1999/12/22 21:45:12     1.1.1.3
--- alpha-linux.mh      2000/03/02 23:15:59
***************
*** 2,8 ****
  XDEPFILES= ser-tcp.o
  XM_FILE= xm-alphalinux.h
  NAT_FILE= nm-linux.h
! NATDEPFILES= infptrace.o inftarg.o corelow.o core-regset.o alpha-nat.o \
        fork-child.o solib.o linux-thread.o lin-thread.o 
  
  LOADLIBES = -ldl -rdynamic
--- 2,8 ----
  XDEPFILES= ser-tcp.o
  XM_FILE= xm-alphalinux.h
  NAT_FILE= nm-linux.h
! NATDEPFILES= infptrace.o inftarg.o corelow.o alpha-nat.o \
        fork-child.o solib.o linux-thread.o lin-thread.o 
  
  LOADLIBES = -ldl -rdynamic

Index: ChangeLog
===================================================================
RCS file: /cvs/src/src/gdb/ChangeLog,v
retrieving revision 1.95
diff -c -r1.95 ChangeLog
*** ChangeLog   2000/03/02 15:44:27     1.95
--- ChangeLog   2000/03/02 23:17:32
***************
*** 1,3 ****
--- 1,8 ----
+ 2000-03-02  Elena Zannoni  <ezannoni@kwikemart.cygnus.com>
+ 
+       * config/alpha/alpha-linux.mh: Remove core-regset.o fron the
+       NATDEPFILES list.
+