Re: path for gdb/dwarf2read.c, support 16-bit targets in dwarf-2

[Fernando Nasser <fnasser@cygnus.com>]

Jim Blandy wrote:
> 
> I've reached the same conclusion on a project I'm doing right now.  I
> think this test is bogus.
> 
It seems that we have a consensus.

Jim, will you do the honors and get Stephane patch in (thus removing the offending test)?

-- 
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 dan@cgsoftware.com Sat Apr 01 00:00:00 2000
From: dan@cgsoftware.com (Daniel Berlin)
To: gdb-patches@sourceware.cygnus.com
Subject: [RFA] Demangled minsym hash table broken
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <pusd46y7.fsf@dan.resnet.rochester.edu>
X-SW-Source: 2000-q1/msg01115.html
Content-length: 839

I was trying to debug a bug report, and in the process, noticed that
the demangled minsym hash table is broken (I noticed because we
weren't finding a symbol we should have been able to find).
Since add_minsym_to_hashtable only uses minsym_hash, and the code
adding to the demangled minsym hashtable is using that function, the
symbols never get the right hash value, because they need to use
minsym_hash_iw.
The lookups properly use that function.

My fix is to add an extra parameter to add_minsym_to_hashtable so we
can tell the function whether we are adding a mangled or demangled
symbol, and thus, it can pick the right bucket.
Also, i made it set the proper next as well (we need to set
sym->demangled_hash_next if it's a demangled symbol).

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

--Dan
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Michael Snyder <msnyder@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH] Document the ThreadInfo remote protocol queries
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38D85C2F.FF89881D@cygnus.com>
References: <200003202316.PAA07888@cleaver.cygnus.com> <38D6FCE2.EBD9830F@cygnus.com> <38D7C38C.6CB0@cygnus.com>
X-SW-Source: 2000-q1/msg00896.html
Content-length: 2117

Michael Snyder wrote:

> > An additional note on these versions of thread queries.  While
> > significantly better than the ``qL'' packet these commands still have
> > problems.  I'll add notes expanding on this.  Briefly, however:
> >
> >         o       Per the query packet spec, they should be
> >                 prefixed with a UCASE letter if they
> >                 are to be official GDB packets.
> >
> >         o       The ``sThread..'' command assumes
> >                 that the GDB protocol is reliable
> >                 which it is not.  GDB can re-issue
> >                 a ``sThread'' request and this can
> >                 lead to GDB and the target falling
> >                 out of sync.
> 
> How about if the 'sThread' request were to be suffixed with
> the last thread ID received?

I was thinking of deprecating fThreadInfo and sThreadInfo and having gdb
try:

	qThreadInfo
	qThreadInfo,<sentinal>

Where sentinal could be <last-thread-id> index (counting from zero) for
next threads, or anything else.

Given ``sThreadInfo'' is in the field, we can't change it.


> > with regard to ``qfThreadExtraInfo''.  As far as I know its not been
> > deployed in the field.  Is there any reason to not name it correctly
> > from the start  (``qThreadExtraInfo'')?
> 
> Only that it conflicts with the tracepoint messages,
> which all begin with qT (see tracepoint.c).

I don't think that is a problem.  The protocol requires:

@tab @code{q}@var{query}
@tab
Request info about @var{query}.  In general @value{GDBN} @var{query}'s
have a leading upper case letter.  Custom vendor queries should use a
company prefix (in lower case) ex: @samp{qfsf.var}.  @var{query} may
optionally be followed by a @samp{,} or @samp{;} separated list.  Stubs
must ensure that they match the full @var{query} name.

The last sentence is ment to ensure that the target's query handling
code matches using something like:
	strcmp (packet, "qThreadInfo")
instead of
	packet[0] == 'q' && packet[1] == 'T' && packet[7] == 'I'


Should ``C'' also be suceeded by something like ``qThread''?  Is ``C''
still used?

	Andrew
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: jtc@redback.com
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: RFA: list which remote protocol commands are required
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38D6F87E.9EE3E726@cygnus.com>
References: <5md7opufwl.fsf@jtc.redbacknetworks.com>
X-SW-Source: 2000-q1/msg00844.html
Content-length: 543

"J.T. Conklin" wrote:
> 
> I submit the enclosed patch for approval.  The existing documentation
> labled some remote protocol commands as optional, while in fact most
> commands are.  This patch removes the "optional" tag from the table
> of commands, and explicitly lists the required commands.

It's fine from my end.  Stan?

As an asside (again, Hi Stan :-).  There was once put forward a proposal
to move the protocol definition (an internal interface that the embedded
user needs to know about) into its own chapter.  Thoughts?

	Andrew
From msnyder@cygnus.com Sat Apr 01 00:00:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: Andrew Hobson <ahobson@eng.mindspring.net>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: PATCH for alphaev56-dec-osf5.0: MERGEPID undefined
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38A2DA3F.649E@cygnus.com>
References: <kjvh3yxd4l.fsf@gamma.eng.mindspring.net>
X-SW-Source: 2000-q1/msg00112.html
Content-length: 1484

Yes, this is good.  Can someone who's working today check it
in?  Andrew?  JimB?
				Thanks,
				Michael

Andrew Hobson wrote:
> 
> I checked out gdb 5.0 from CVS today and found a minor compilation
> issue.  In procfs.c, I find:
> 
> /* Provide default composite pid manipulation macros for systems that
>    don't have threads. */
> 
> #ifndef PIDGET
> #define PIDGET(PID)             (PID)
> #define TIDGET(PID)             (PID)
> #define MERGEPID(PID, TID)      (PID)
> #endif
> 
> ... but in defs.h I find:
> 
> /* On some systems, PIDGET is defined to extract the inferior pid from
>    an internal pid that has the thread id and pid in seperate bit
>    fields.  If not defined, then just use the entire internal pid as
>    the actual pid. */
> 
> #ifndef PIDGET
> #define PIDGET(PID) (PID)
> #define TIDGET(PID) 0
> #endif
> 
> That leaves MERGEPID undefined.  I'm not positive of the correct fix,
> but the following patch solves the problem for me.
> 
> Drew
> 
> Index: defs.h
> ===================================================================
> RCS file: /cvs/src/src/gdb/defs.h,v
> retrieving revision 1.1.1.31
> diff -u -p -r1.1.1.31 defs.h
> --- defs.h      2000/02/05 07:29:41     1.1.1.31
> +++ defs.h      2000/02/09 20:52:56
> @@ -1218,6 +1218,7 @@ extern int use_windows;
>  #ifndef PIDGET
>  #define PIDGET(PID) (PID)
>  #define TIDGET(PID) 0
> +#define MERGEPID(PID, TID) (PID)
>  #endif
> 
>  /* If under Cygwin, provide backwards compatibility with older
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: [MAINT] J.T. NetBSD maintainer
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38DE9D40.D6CD27B4@cygnus.com>
X-SW-Source: 2000-q1/msg01039.html
Content-length: 100

FYI,

I've put J.T. down as the NetBSD maintainer.

NetBSD			J.T. Conklin		jtc@redback.com

	Andrew
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: BINUTILS Patches <binutils@sourceware.cygnus.com>, GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: [PATCH-DEJAGNU]  Force DMAP2 register when running d10v tests
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38ABC120.2BF81A6F@cygnus.com>
X-SW-Source: 2000-q1/msg00219.html
Content-length: 924

Hello,

I don't see anyone objecting to the test.  I'm just what the commit
policy for this part of the repository is.

	enjoy,
		Andrew
Thu Feb 17 20:24:21 2000  Andrew Cagney  <cagney@b1.cygnus.com>

	* baseboards/d10v.exp (gdb_init_command): Force register DMAP2 to
 	0x2000 so that the d10v VM matches the simulator.

Index: baseboards/d10v.exp
===================================================================
RCS file: /cvs/cvsfiles/devo/dejagnu/baseboards/d10v.exp,v
retrieving revision 1.12
diff -p -r1.12 d10v.exp
*** d10v.exp	1999/09/15 20:49:56	1.12
--- d10v.exp	2000/02/17 09:30:06
*************** set_board_info gcc,no_label_values  1
*** 54,56 ****
--- 54,60 ----
  
  # sizeof int != sizeof long.
  set_board_info gdb,short_int 1
+ 
+ # Some d10v:ts3 boards are in ts2-board compatibility mode after a reset.
+ # Force it into d10v:ts3 internal mode
+ set_board_info gdb_init_command "set \$dmap2 = 0x2000"
From kevinb@cygnus.com Sat Apr 01 00:00:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH] Shared library fixes for GNU/Linux/PPC port
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <1000225030334.ZM15636@ocotillo.lan>
References: <1000225014927.ZM15386@ocotillo.lan> <38B5E8EB.22A8C2A0@cygnus.com> <ac131313@cygnus.com>
X-SW-Source: 2000-q1/msg00364.html
Content-length: 2757

On Feb 25,  1:28pm, Andrew Cagney wrote:

> >     The differences between ppc_linux_memory_remove_breakpoint () and
> >     memory_remove_breakpoint () are minor.  All that the former does
> >     that the latter does not is check to make sure that the breakpoint
> >     location actually contains a breakpoint (trap instruction) prior
> >     to attempting to write back the old contents.  If it does contain
> >     a trap instruction, we allow the old contents to be written back.
> >     Otherwise, we silently do nothing.
> > 
> >     It seems to me that we ought to be using this version in
> >     mem-break.c for all other targets (using the mem-break.c
> >     facilities) too.  The only downside that more traffic is generated
> >     for remote targets since we'll have an extra fetch of a memory
> >     word each time a breakpoint is removed.
> 
> Rather than make this the default behavour (and introduce extra remote
> traffic) would it be better to provide this behavour as a new type of
> breakpoint?  The shlib stuff could then insert a checking breakpoint.

I'll have to study it some more.  It sounds like a good idea, but I
think we'll have to complicate the breakpoint machinery somewhat to
insert these special breakpoints.  (For this particular platform, we'd
insert the special breakpoint when the address in question is in a
PLT.)

> I'd also be curious to know if this shlib mechanism is standard for
> SVR4/PPC or just Linux.

From my reading of the SVR4/PPC ABI, it looks like it's standard.  The
following text is especially relevant:

    For the PowerPC, the procedure linkage table (the .plt section) is
                                                                    ^^
    not initialized in the executable or shared object file.  Instead,
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    the link editor simply reserves space for it and the dynamic
    linker initializes it and manages it according to its own,
    possibly implementation-dependent needs, subject to the following
    constraints:

    1. The first 18 words (72 bytes) of the procedure linkage table
       are reserved for use by the dynamic linker.  There shall be no
       branches from the executable or shared object into these first
       18 words.

    2.  If the executable or shared object requires N procedure
       linkage table entries, the link editor shall reserve 3*N words
       (12*N bytes) following the 18 reserved words.  The first 2*N of
       these words are the procedure linkage table entries themselves. 
       The static linker directs calls to bytes (72 + (i-1)*8), for i
       between 1 and N inclusive.  The remaining N words (4*N bytes)
       are reserved for use by the dynamic linker.

Kevin
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Jim Blandy <jimb@cygnus.com>, Jimmy Guo <guo@cup.hp.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: 2nd try: (patch) hpjyg03: (buildsym|language).[ch]
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38B0ABEF.8EDEAA53@cygnus.com>
References: <Pine.LNX.4.10.9911011130300.30664-100000@hpcll168.cup.hp.com> <npso2pkf00.fsf@zwingli.cygnus.com> <npg0uqp30k.fsf@zwingli.cygnus.com> <38B0A4A0.D9109A9E@cygnus.com>
X-SW-Source: 2000-q1/msg00265.html
Content-length: 1693

Andrew Cagney wrote:
> 

> Unfortunatly, there is no prototype for longest_local_hex_string()
> visible in buildsym.c.  I've ended up commiting the following.

Oops!

"language.h" depends on "expression.h".  I've also checked in the
attatched.

	sorry,
		Andrew
? 2diffs
? diffs
? old_wait.h
? %redact.run
? netscape.core
? new-gdbarch
? new-gdbarch.h
? new-gdbarch.c
Index: ChangeLog
===================================================================
RCS file: /cvs/src/src/gdb/ChangeLog,v
retrieving revision 1.50
diff -p -r1.50 ChangeLog
*** ChangeLog	2000/02/21 02:51:07	1.50
--- ChangeLog	2000/02/21 03:01:59
***************
*** 1,6 ****
  Mon Feb 21 12:50:57 2000  Andrew Cagney  <cagney@b1.cygnus.com>
  
! 	* buildsym.c: Include "language.h" for
   	longest_local_hex_string_custom.
  
  Mon Feb 21 11:17:18 2000  Andrew Cagney  <cagney@b1.cygnus.com>
--- 1,6 ----
  Mon Feb 21 12:50:57 2000  Andrew Cagney  <cagney@b1.cygnus.com>
  
! 	* buildsym.c: Include "language.h" and "expression.h" for
   	longest_local_hex_string_custom.
  
  Mon Feb 21 11:17:18 2000  Andrew Cagney  <cagney@b1.cygnus.com>
Index: buildsym.c
===================================================================
RCS file: /cvs/src/src/gdb/buildsym.c,v
retrieving revision 1.3
diff -p -r1.3 buildsym.c
*** buildsym.c	2000/02/21 02:51:07	1.3
--- buildsym.c	2000/02/21 03:02:02
***************
*** 34,39 ****
--- 34,40 ----
  #include "gdbtypes.h"
  #include "complaints.h"
  #include "gdb_string.h"
+ #include "expression.h"		/* For "enum exp_opcode" used by... */
  #include "language.h"		/* For "longest_local_hex_string_custom" */
  
  /* Ask buildsym.h to define the vars it normally declares `extern'.  */
From jtc@redback.com Sat Apr 01 00:00:00 2000
From: jtc@redback.com (J.T. Conklin)
To: "Philippe De Muyter" <phdm@macqel.be>
Cc: gdb-patches@sourceware.cygnus.com (gdb-patches@sourceware.cygnus.com), dan@cgsoftware.com
Subject: Re: regerror link error
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <5m8zz8vviv.fsf@jtc.redbacknetworks.com>
References: <200003242151.WAA07612@mail.macqel.be>
X-SW-Source: 2000-q1/msg01006.html
Content-length: 619

>>>>> "Philippe" == Philippe De Muyter <phdm@macqel.be> writes:
Philippe> makes the compilation of gdb fail on my system (m68k-motorola-sysv) :
Philippe> [...] 

Philippe> Actually, I have found a __regerror, but no regerror.  How
Philippe> can we fix that ?

I think the __regerror() function in gnu-regex.c needs to be renamed
regerror().  All the other functions in that file are defined without
leading double-underscores with a weak_alias() which I assume maps the
two forms together in glibc.  It certainly looks like the underscores
aren't supposed to be there.

        --jtc

-- 
J.T. Conklin
RedBack Networks
From kettenis@wins.uva.nl Sat Apr 01 00:00:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: gdb-patches@sourceware.cygnus.com
Subject: [MAINT] Mail address correction
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003010050.e210opc00296@delius.kettenis.local>
X-SW-Source: 2000-q1/msg00435.html
Content-length: 1126

I noticed that the mail address listed in the MAINTAINERS file wasn't
correct (it was missing one character).  I changed it to my @gnu.org
address since that's likely to be correct as long as my involvement
with the GNU project continues, whereas my university address might
become invalid if I ever manage to finish my Ph.D. :-).

Mark


2000-03-01  Mark Kettenis  <kettenis@gnu.org>

	* MAINTAINERS: Correct my own mail address.


Index: MAINTAINERS
===================================================================
RCS file: /cvs/src/src/gdb/MAINTAINERS,v
retrieving revision 1.15
diff -u -p -r1.15 MAINTAINERS
--- MAINTAINERS	2000/03/01 00:28:35	1.15
+++ MAINTAINERS	2000/03/01 00:42:15
@@ -57,7 +57,7 @@ MS Windows (N.T., CE, '00) host & native
 			Chris Faylor		cgf@cygnus.com
 GNU/Linux x86 native	Jim Blandy		jimb@cygnus.com
 GNU/Linux PPC native	Kevin Buettner		kevinb@cygnus.com
-hurd native		Mark Kettenis		kettenis@wins.va.nl
+hurd native		Mark Kettenis		kettenis@gnu.org
 macos host & native	Stan Shebs		shebs@apple.com
 hpux, hp pa native	Jeff Law		law@cygnus.com
 UnixWare Threads	Nick Duffek		nsd@cygnus.com
From kettenis@wins.uva.nl Sat Apr 01 00:00:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: gdb-patches@sourceware.cygnus.com
Subject: [PATCH] Fix `next'-ing out of a signal handler on Linux/i386 
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003082237.e28Mbre06925@delius.kettenis.local>
X-SW-Source: 2000-q1/msg00603.html
Content-length: 2157

FYI,

I committed the attached patch.  It is now possible to use the `next'
command to step out of a signal handler.  Using `step' however is
still broken.  Making that work will probably require some changes to
`infrun.c'.  But I'm not sure exactly on how to fix it, and even if I
find out, I'm not sure whether I should touch that file before the 5.0
release.

Mark


2000-03-08  Mark Kettenis  <kettenis@gnu.org>

	* i386-tdep.c (i386_linux_saved_pc_after_call): New function.
	* config/i386/tm-linux.h (SAVED_PC_AFTER_CALL): Define to call
	i386_linux_saved_pc_after_call.


Index: i386-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/i386-tdep.c,v
retrieving revision 1.5
diff -u -p -r1.5 i386-tdep.c
--- i386-tdep.c	2000/03/04 23:37:33	1.5
+++ i386-tdep.c	2000/03/08 22:32:34
@@ -1024,6 +1024,17 @@ i386_linux_sigtramp_saved_sp (struct fra
   return read_memory_integer (addr + LINUX_SIGCONTEXT_SP_OFFSET, 4);
 }
 
+/* Immediately after a function call, return the saved pc.  */
+
+CORE_ADDR
+i386_linux_saved_pc_after_call (struct frame_info *frame)
+{
+  if (frame->signal_handler_caller)
+    return i386_linux_sigtramp_saved_pc (frame);
+
+  return read_memory_integer (read_register (SP_REGNUM), 4);
+}
+
 #endif /* I386_LINUX_SIGTRAMP */
 
 #ifdef STATIC_TRANSFORM_NAME
Index: config/i386/tm-linux.h
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/tm-linux.h,v
retrieving revision 1.2
diff -u -p -r1.2 tm-linux.h
--- config/i386/tm-linux.h	2000/03/04 23:37:33	1.2
+++ config/i386/tm-linux.h	2000/03/08 22:32:34
@@ -154,6 +154,10 @@ extern CORE_ADDR i386_linux_sigtramp_sav
 
 extern CORE_ADDR i386_linux_sigtramp_saved_sp (struct frame_info *);
 
+#undef SAVED_PC_AFTER_CALL
+#define SAVED_PC_AFTER_CALL(frame) i386_linux_saved_pc_after_call (frame)
+extern CORE_ADDR i386_linux_saved_pc_after_call (struct frame_info *);
+
 /* When we call a function in a shared library, and the PLT sends us
    into the dynamic linker to find the function's real address, we
    need to skip over the dynamic linker call.  This function decides
From eliz@delorie.com Sat Apr 01 00:00:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: Mark Kettenis <kettenis@wins.uva.nl>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: Linux sigtramp detection code moved to its proper place
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003201529.KAA10589@indy.delorie.com>
References: <200003201214.e2KCEYK00493@delius.kettenis.local>
X-SW-Source: 2000-q1/msg00816.html
Content-length: 414

>   What would you suggest for a non-buggy Tar program to do, exactly?
>
> Simply overwrite the files, possibly asking confirmation from the
> user.  This shouldn't be a problem, since the DJGPP native port
> doesn't need i386-linux-nat.c nor i386-linux-tdep.c.

The users don't know whether these files are or aren't needed.  So
they might overwrite the wrong files, and mess up the build beyond
any recognition.
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Jim Blandy <jimb@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH] Don't trim addresses in Dwarf debug info
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38E2B5C6.3451444B@cygnus.com>
References: <200003281624.LAA23161@zwingli.cygnus.com> <38E12BD6.E6E357A4@cygnus.com> <npvh251yvu.fsf@zwingli.cygnus.com>
X-SW-Source: 2000-q1/msg01120.html
Content-length: 996

Jim Blandy wrote:
> 
> > > I've committed this:
> > >
> > > 2000-03-27  Jim Blandy  <jimb@redhat.com>
> > >
> > >         * dwarf2read.c: Revert Andrew Cagney's change of Dec 15, 1997.
> > >         Don't include "bfd-elf.h".
> > >         (address_significant_size): Delete variable.
> > >         (dwarf2_build_psymtabs_hard): Don't set it, or check for
> > >         consistency between it and the Dwarf 2 compilation unit header
> > >         address size.
> > >         (read_address): Don't mask off bits above
> > >         address_significant_size.
> > >         * Makefile.in (dwarf2read.o): Don't depend on $(elf_bfd_h).
> > >         (elf_bfd_h): Remove variable; it's no longer used.
> >
> > Jim, have you confirmed this doesn't cause any regressions?
> 
> It fixes problems for me, and it fixes the problems Stephane Carrez
> reported.  It might possibly cause regressions on 64-bit hosts, but
> here's why I committed it anyway:

What specific problems was it causing you?

	Andrew
From grante@visi.com Sat Apr 01 00:00:00 2000
From: Grant Edwards <grante@visi.com>
To: gdb-patches@sourceware.cygnus.com
Subject: Re: Patch for RDI target code to allow user-specified devices
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000221142049.A31223@visi.com>
References: <20000221141155.A31206@visi.com>
X-SW-Source: 2000-q1/msg00285.html
Content-length: 577

> The attached patch against 4.18 sources modifies the RDI target
> unix comm code to allow users to specify any device they please
> to be used for serial and/or parallel communication with the
> target.

NB: The patch was generated from 4.18 sources that already
    contained some other RDI patches.  This patch is independant
    of the others, so it can be applied to clean 4.18 sources,
    but you'll see a notice about one of the hunks being offset.
    
    Not that you want to use the RDI target without those other
    patches...

-- 
Grant Edwards
grante@visi.com
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] MI - post comment
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38B0EF83.A7F80182@cygnus.com>
X-SW-Source: 2000-q1/msg00275.html
Content-length: 137

Just FYI,

This still won't appear for a day or so.  I'll give people a day or so
to chew on it first :-)

	nice day for it...

		Andrew
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Mark Kettenis <kettenis@wins.uva.nl>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH] Fix for target.c:do_target_signal_to_host()
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38AB1EAD.90CE4860@cygnus.com>
References: <200002142116.e1ELGrL06391@delius.kettenis.local> <38A90F10.E61AF586@cygnus.com> <200002161532.e1GFWaf03903@delius.kettenis.local>
X-SW-Source: 2000-q1/msg00206.html
Content-length: 564

Mark Kettenis wrote:
 
> While adding the comments I noticed that the function will return 32
> for TARGET_SIGNAL_REALTIME_32 even if it doesn't exist, and that (with
> my patch) for the other RT signals the upper bound was checked, but
> not the lower bound.  Not likely to be very problematic, but this is
> not right according to the comment at the top of the function.
> 
> I also moved the TARGET_SIGNAL_REALTIME_32 case within the
> default: where the other RT signals are handled.  I think this
> makes it easier to understand the code.

Yes.  Ok.

	Andrew
From kettenis@wins.uva.nl Sat Apr 01 00:00:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: gdb-patches@sourceware.cygnus.com
Cc: jtc@redback.com
Subject: [PATCH] Restructuring i386-tdep.c:i386_extract_return_value()
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003220949.e2M9nl001746@delius.kettenis.local>
X-SW-Source: 2000-q1/msg00899.html
Content-length: 6153

Hi,

I checked in the attached patch.  This is one of the patches I
discussed two weeks ago, which makes i386_extract_return_value() do
the right thing for most of the supported i386 targets.  Some targets
(for example those that use tm-i386v.h) still redefine
EXTRACT_RETURN_VALUE, so they don't take advantage of this
improvement.  I'll deal with that later.

Mark


2000-03-22  Mark Kettenis  <kettenis@gnu.org>

	* config/i386/tm-i386aix.h (I386_AIX_TARGET): Remove.
	* config/i386/tm-linux.h (LOW_RETURN_REGNUM, HIGH_RETURN_REGNUM):
	Remove
	* i386-tdep.c (LOW_RETURN_REGNUM, HIGH_RETURN_REGNUM): New defines.
	(i386_extract_return_value): Rewritten.  Correctly support all
	floating-point types and large integer types on targets that use
	the standard i386 GDB register layout and return floating-point
	values in the FPU.


Index: config/i386/tm-i386aix.h
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/tm-i386aix.h,v
retrieving revision 1.2
diff -u -p -r1.2 tm-i386aix.h
--- config/i386/tm-i386aix.h	2000/03/02 15:44:27	1.2
+++ config/i386/tm-i386aix.h	2000/03/22 09:41:10
@@ -30,14 +30,6 @@
 #define I386 1
 #endif
 
-/* FIXME: kettenis/2000-03-02: This is used in
-   i386-tdep.c:i386_extract_return_value(), and will be remove once
-   I've fixed that.  Meanwhile don't use it for any other purpose
-   please!  */
-#ifndef I386_AIX_TARGET
-#define I386_AIX_TARGET 1
-#endif
-
 /* AIX/i386 has FPU support.  However, the native configuration (which
    is the only supported configuration) doesn't make the FPU control
    registers available.  Override the appropriate symbols such that
Index: config/i386/tm-linux.h
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/tm-linux.h,v
retrieving revision 1.4
diff -u -p -r1.4 tm-linux.h
--- config/i386/tm-linux.h	2000/03/16 22:46:30	1.4
+++ config/i386/tm-linux.h	2000/03/22 09:41:10
@@ -30,9 +30,6 @@
 #include "i386/tm-i386.h"
 #include "tm-linux.h"
 
-#define LOW_RETURN_REGNUM 0	/* holds low four bytes of result */
-#define HIGH_RETURN_REGNUM 2	/* holds high four bytes of result */
-
 /* This should probably move to tm-i386.h.  */
 #define TARGET_LONG_DOUBLE_BIT 80
 
Index: i386-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/i386-tdep.c,v
retrieving revision 1.7
diff -u -p -r1.7 i386-tdep.c
--- i386-tdep.c	2000/03/16 22:46:26	1.7
+++ i386-tdep.c	2000/03/22 09:41:10
@@ -698,56 +698,66 @@ get_longjmp_target (pc)
 
 #endif /* GET_LONGJMP_TARGET */
 
+/* These registers are used for returning integers (and on some
+   targets also for returning `struct' and `union' values when their
+   size and alignment match an integer type.  */
+#define LOW_RETURN_REGNUM 0	/* %eax */
+#define HIGH_RETURN_REGNUM 2	/* %edx */
+
+/* Extract from an array REGBUF containing the (raw) register state, a
+   function return value of TYPE, and copy that, in virtual format,
+   into VALBUF.  */
+
 void
-i386_extract_return_value (type, regbuf, valbuf)
-     struct type *type;
-     char regbuf[REGISTER_BYTES];
-     char *valbuf;
+i386_extract_return_value (struct type *type, char *regbuf, char *valbuf)
 {
-  /* On AIX, i386 GNU/Linux and DJGPP, floating point values are
-     returned in floating point registers.  */
-  /* FIXME: cagney/2000-02-29: This function needs to be rewritten
-     using multi-arch. Please don't keep adding to this #ifdef
-     spaghetti. */
-#if defined(I386_AIX_TARGET) || defined(I386_GNULINUX_TARGET) || defined(I386_DJGPP_TARGET)
+  int len = TYPE_LENGTH (type);
+
   if (TYPE_CODE_FLT == TYPE_CODE (type))
     {
-      double d;
-      /* 387 %st(0), gcc uses this */
-      floatformat_to_double (&floatformat_i387_ext,
-#if defined(FPDATA_REGNUM)
-			     &regbuf[REGISTER_BYTE (FPDATA_REGNUM)],
-#else /* !FPDATA_REGNUM */
-			     &regbuf[REGISTER_BYTE (FP0_REGNUM)],
-#endif /* FPDATA_REGNUM */
+      if (NUM_FREGS == 0)
+	{
+	  warning ("Cannot find floating-point return value.");
+	  memset (valbuf, 0, len);
+	}
 
-			     &d);
-      store_floating (valbuf, TYPE_LENGTH (type), d);
+      /* Floating-point return values can be found in %st(0).  */
+      if (len == TARGET_LONG_DOUBLE_BIT / TARGET_CHAR_BIT
+	  && TARGET_LONG_DOUBLE_FORMAT == &floatformat_i387_ext)
+	{
+	  /* Copy straight over, but take care of the padding.  */
+	  memcpy (valbuf, &regbuf[REGISTER_BYTE (FP0_REGNUM)],
+		  FPU_REG_RAW_SIZE);
+	  memset (valbuf + FPU_REG_RAW_SIZE, 0, len - FPU_REG_RAW_SIZE);
+	}
+      else
+	{
+	  /* Convert the extended floating-point number found in
+             %st(0) to the desired type.  This is probably not exactly
+             how it would happen on the target itself, but it is the
+             best we can do.  */
+	  DOUBLEST val;
+	  floatformat_to_doublest (&floatformat_i387_ext,
+				   &regbuf[REGISTER_BYTE (FP0_REGNUM)], &val);
+	  store_floating (valbuf, TYPE_LENGTH (type), val);
+	}
     }
   else
-#endif /* I386_AIX_TARGET || I386_GNULINUX_TARGET || I386_DJGPP_TARGET */
     {
-#if defined(LOW_RETURN_REGNUM)
-      int len = TYPE_LENGTH (type);
       int low_size = REGISTER_RAW_SIZE (LOW_RETURN_REGNUM);
       int high_size = REGISTER_RAW_SIZE (HIGH_RETURN_REGNUM);
 
       if (len <= low_size)
-	memcpy (valbuf, regbuf + REGISTER_BYTE (LOW_RETURN_REGNUM), len);
+	memcpy (valbuf, &regbuf[REGISTER_BYTE (LOW_RETURN_REGNUM)], len);
       else if (len <= (low_size + high_size))
 	{
 	  memcpy (valbuf,
-		  regbuf + REGISTER_BYTE (LOW_RETURN_REGNUM),
-		  low_size);
+		  &regbuf[REGISTER_BYTE (LOW_RETURN_REGNUM)], low_size);
 	  memcpy (valbuf + low_size,
-		  regbuf + REGISTER_BYTE (HIGH_RETURN_REGNUM),
-		  len - low_size);
+		  &regbuf[REGISTER_BYTE (HIGH_RETURN_REGNUM)], len - low_size);
 	}
       else
-	error ("GDB bug: i386-tdep.c (i386_extract_return_value): Don't know how to find a return value %d bytes long", len);
-#else /* !LOW_RETURN_REGNUM */
-      memcpy (valbuf, regbuf, TYPE_LENGTH (type));
-#endif /* LOW_RETURN_REGNUM */
+	internal_error ("Cannot extract return value of %d bytes long.", len);
     }
 }
 
From fnasser@cygnus.com Sat Apr 01 00:00:00 2000
From: Fernando Nasser <fnasser@cygnus.com>
To: Scott Bambrough <scottb@netwinder.org>
Cc: 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: <38CEA1FF.CEA9553@cygnus.com>
References: <38CE9C8B.3EC5B7F1@netwinder.org>
X-SW-Source: 2000-q1/msg00695.html
Content-length: 712

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
> 


-- 
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 phdm@macqel.be Sat Apr 01 00:00:00 2000
From: "Philippe De Muyter" <phdm@macqel.be>
To: gdb-patches@sourceware.cygnus.com (gdb-patches@sourceware.cygnus.com), dan@cgsoftware.com
Subject: regerror link error
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003242151.WAA07612@mail.macqel.be>
X-SW-Source: 2000-q1/msg01000.html
Content-length: 845

The following patch :

2000-03-22  Daniel Berlin  <dan@cgsoftware.com>
        * command.c (apropos_cmd_helper): New function, meat of the
        apropos command.
        (apropos_command): New apropos command to search command
        names/documentation for regular expressions.
        (_initialize_command): Add the apropos command.

makes the compilation of gdb fail on my system (m68k-motorola-sysv) :

gcc -g -O2 -W -Wall        -o gdb main.o libgdb.a    ../bfd/libbfd.a ../readline
/libreadline.a ../opcodes/libopcodes.a ./../intl/libintl.a ../libiberty/libibert
y.a -lncurses     -lm  ../libiberty/libiberty.a
libgdb.a(command.o): In function `apropos_command':
command.c:481: undefined reference to `regerror'
collect2: ld returned 1 exit status

Actually, I have found a __regerror, but no regerror.  How can we fix that ?

Philippe
From ezannoni@cygnus.com Sat Apr 01 00:00:00 2000
From: Elena Zannoni <ezannoni@cygnus.com>
To: Mark Kettenis <kettenis@wins.uva.nl>
Cc: ac131313@cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: GDB-5 2000-03-03
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <14527.59027.494800.595466@kwikemart.cygnus.com>
References: <38BFBD74.79263683@cygnus.com> <200003031556.e23FuCm00326@delius.kettenis.local>
X-SW-Source: 2000-q1/msg00475.html
Content-length: 3428

Mark, sigh, that's my fault. I made some changes to the MI disassemble
interface and haven't had a chance to update the tests. I'll try to
get to that before Monday.

Elena


Mark Kettenis writes:
 >    Date: Sat, 04 Mar 2000 00:26:12 +1100
 >    From: Andrew Cagney <ac131313@cygnus.com>
 > 
 >    MI tests
 > 
 >    The MI testsuite falls over (lots of dejagnu errors) when the MI wasn't
 >    build. 
 > 
 > Even if I build MI, there are quite a few dejagnu errors:
 > 
 > ERROR: Undefined command "-file-clear".
 > UNRESOLVED: gdb.mi/mi-basics.exp: file-clear operation
 > 
 > FAIL: gdb.mi/mi-console.exp: Hello message (timeout)
 > ...
 > FAIL: gdb.mi/mi-disassemble.exp: data-disassemble from pc assembly only
 > FAIL: gdb.mi/mi-disassemble.exp: data-disassemble main assembly only
 > FAIL: gdb.mi/mi-disassemble.exp: data-disassemble range assembly only
 > FAIL: gdb.mi/mi-disassemble.exp: data-disassemble callee2 assembly only
 > FAIL: gdb.mi/mi-disassemble.exp: data-disassemble callee2 assembly mixed
 > FAIL: gdb.mi/mi-disassemble.exp: data-disassemble range assembly mixed
 > FAIL: gdb.mi/mi-disassemble.exp: data-disassemble callee2 assembly mixed
 > FAIL: gdb.mi/mi-disassemble.exp: data-disassemble bogus arguments
 > FAIL: gdb.mi/mi-disassemble.exp: data-disassemble wrong num of args (3)
 > FAIL: gdb.mi/mi-disassemble.exp: data-disassemble wrong num of args (2)
 > FAIL: gdb.mi/mi-disassemble.exp: data-disassemble wrong num of args (1)
 > FAIL: gdb.mi/mi-disassemble.exp: data-disassemble from pc two lines - assembly only
 > FAIL: gdb.mi/mi-disassemble.exp: data-disassemble main 1 line - assembly only
 > FAIL: gdb.mi/mi-disassemble.exp: data-disassemble main zero lines - assembly only
 > FAIL: gdb.mi/mi-disassemble.exp: data-disassemble lines bigger than range - assembly only
 > FAIL: gdb.mi/mi-disassemble.exp: data-disassemble lines less than range - assembly only
 > FAIL: gdb.mi/mi-disassemble.exp: data-disassemble from pc two lines - assembly mixed
 > FAIL: gdb.mi/mi-disassemble.exp: data-disassemble main 1 line - assembly mixed
 > FAIL: gdb.mi/mi-disassemble.exp: data-disassemble main zero lines - assembly mixed
 > FAIL: gdb.mi/mi-disassemble.exp: data-disassemble lines bigger than range - assembly mixed
 > FAIL: gdb.mi/mi-disassemble.exp: data-disassemble lines less than range - assembly mixed
 > ...
 > FAIL: gdb.mi/mi-disassemble.exp: data-disassemble from pc assembly mixed
 > ...
 > FAIL: gdb.mi/mi-simplerun.exp: exec-finish (timeout)
 > FAIL: gdb.mi/mi-simplerun.exp: continue to end (1)
 > ...
 > FAIL: gdb.mi/mi-stack.exp: stack args listing 0
 > ...
 > FAIL: gdb.mi/mi-stack.exp: stack args listing 1
 > ...
 > FAIL: gdb.mi/mi-stack.exp: stack info-depth
 > ...
 > FAIL: gdb.mi/mi-stack.exp: stack info-depth 99
 > ...
 > FAIL: gdb.mi/mi-var-child.exp: update all vars psnp->next->long_ptr (and 1.long_ptr) changed
 > ...
 > FAIL: gdb.mi/mi-var-cmd.exp: update all vars: changed FIXME
 > ...
 > FAIL: gdb.mi/mi-watch.exp: list of watchpoints
 > ...
 > FAIL: gdb.mi/mi-watch.exp: wp out of scope (2)
 > 
 > 
 > Here's the summary for i586-pc-linux-gnu:
 > 
 > 		=== gdb Summary ===
 > 
 > # of expected passes		6827
 > # of unexpected failures	45
 > # of expected failures		212
 > # of unresolved testcases	1
 > /mnt/hdb4/obj/src/gdb/testsuite/../../gdb/gdb version  20000204 -nx
 > 
 > The majority of all those unexpected failures is because of the MI
 > problems.
 > 
 > Mark
From nsd@cygnus.com Sat Apr 01 00:00:00 2000
From: nsd@cygnus.com
To: john@feith.com
Cc: cgf@cygnus.com, eliz@delorie.com, gdb-patches@sourceware.cygnus.com, jimb@cygnus.com, msnyder@cygnus.com
Subject: Re: GDB 4.17 Patch for stack aligned i386 code
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003250054.AAA07709@nog.bosbc.com>
References: <200003250030.TAA14328@jwlab.FEITH.COM>
X-SW-Source: 2000-q1/msg01015.html
Content-length: 314

>I'm not sure what I still have laying around other than a very old patch
>for GCC.  The idea is to handle a prologue which looks like:

Thanks, that makes it clear.

At the moment, I don't think my patch would handle that correctly.  The
"tightening up" that I mentioned earlier might do the trick, though.

Nick
From kingdon@redhat.com Sat Apr 01 00:00:00 2000
From: Jim Kingdon <kingdon@redhat.com>
To: "Peter.Schauer" <Peter.Schauer@regent.e-technik.tu-muenchen.de>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: Problem with gdb/objfiles.c and --with-mmalloc + fix
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <bg0uepm83.fsf@rtl.cygnus.com>
References: <200002232157.WAA26169@reisser.regent.e-technik.tu-muenchen.de>
X-SW-Source: 2000-q1/msg00382.html
Content-length: 325

> I have used --with-mmalloc with GDB configure for a long time to get sort of
> a poor man's purify. Unfortunately gdb/objfiles.c suffered some bitrot
> during the last year, here is a fix:

Looks like a straightforward bugfix to me.

Maintainer is JimB (if objfiles.c is part of "generic symtabs") or
Andrew/Stan (if not).
From eliz@delorie.com Sat Apr 01 00:00:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: ac131313@cygnus.com
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: GDB 5 2000-03-29
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003312306.SAA07143@indy.delorie.com>
References: <38E17D2C.F7EB65B9@cygnus.com>
X-SW-Source: 2000-q1/msg01141.html
Content-length: 1747

> For the watchpoint patches, if at least some have been addressed, I'd
> like to put the rest off.

All of them are addressed now.  See below.

> Watch point related patches (Eli Zaretskii, Michael Snyder, ???)
> 
> Eli writes: This doesn't include the watchpoint-related patches I sent
> beginning with August or September, and mentioned them again three
> weeks ago.  Here again are the pointers to the relevant messages:
> 
> Hardware breakpoints and watchpoints: patches
> http://sourceware.cygnus.com/ml/gdb-patches/1999-q3/msg00173.html
> 
> Re: Hardware breakpoints and watchpoints: patches
> http://sourceware.cygnus.com/ml/gdb-patches/1999-q3/msg00204.html
> 
> Re: Hardware breakpoints and watchpoints: patches
> http://sourceware.cygnus.com/ml/gdb-patches/1999-q4/msg00200.html
> 
> Hardware watchpoints for bitfields
> http://sourceware.cygnus.com/ml/gdb-patches/1999-q4/msg00201.html

Michael posted about a week ago several messages saying that my
patches were checked in.  The relevant messages are:

  http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00873.html
  http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00840.html

So I'm quite happy with this (thanks, Michael!).

> +MI documentation in GDB user guide. (Andrew Cagney, Elena Zannoni,
> +Stan Shebs, anyone else?)
> +
> +> (Are there plans to make gdbmi.texi be part of the manual as well?)

If no one objects, I can submit changes to incorporate gdbmi.texi into
the manual.

> +[PATCH] GDB command-line switches and annotations docs
> + http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00639.html

I believe this is already checked in (I commited these patches two weeks
ago).  See

  http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00739.html
From shebs@apple.com Sat Apr 01 00:00:00 2000
From: Stan Shebs <shebs@apple.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: ezannoni@cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH] GDB command-line switches and annotations docs
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38CFF074.B275A986@apple.com>
References: <14537.5048.99180.910863@kwikemart.cygnus.com> <200003101809.NAA22092@indy.delorie.com> <14537.18119.116000.442262@kwikemart.cygnus.com> <200003120754.CAA24393@indy.delorie.com> <14539.49127.700844.807495@kwikemart.cygnus.com> <200003151414.JAA01131@indy.delorie.com>
X-SW-Source: 2000-q1/msg00729.html
Content-length: 560

Eli Zaretskii wrote:
> 
> >  > If it would help, I could add a note telling that the event loop is
> >  > still not fully asynchronous, with a FIXME comment that the note
> >  > should be removed when the target side is done.  Okay?
> >
> > Perfect, thanks!
> 
> I attach below the changes which address the above, and also what Stan
> said about moving the Annotations chapter before the appendices.
> These changes are to be applied _on top_ of those I sent in the
> previous message.
> 
> Is it okay to commit this and the previous patch?

Go for it!

Stan
From jtc@redback.com Sat Apr 01 00:00:00 2000
From: jtc@redback.com (J.T. Conklin)
To: gdb-patches@sourceware.cygnus.com
Subject: RFA: NetBSD/i386 core dump support
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <5msnxhqmiq.fsf@jtc.redbacknetworks.com>
X-SW-Source: 2000-q1/msg00957.html
Content-length: 2618

I submit the enclosed patch for approval.  

This change enables core dump support on NetBSD/i386 and adds floating
point register support to fetch_core_registers().

2000-03-23  J.T. Conklin  <jtc@redback.com>

	* i386nbsd-nat.c (fetch_core_registers): Read fp registers.
	(i386nbsd_core_fns, _initialize_i386nbsd_nat): Added.

Index: i386nbsd-nat.c
===================================================================
RCS file: /cvs/src/src/gdb/i386nbsd-nat.c,v
retrieving revision 1.1
diff -c -3 -p -r1.1 i386nbsd-nat.c
*** i386nbsd-nat.c	2000/03/22 01:36:31	1.1
--- i386nbsd-nat.c	2000/03/23 23:35:03
*************** store_inferior_registers (regno)
*** 152,158 ****
  struct md_core
  {
    struct reg intreg;
!   struct fpreg freg;
  };
  
  void
--- 152,158 ----
  struct md_core
  {
    struct reg intreg;
!   struct env387 freg;
  };
  
  void
*************** fetch_core_registers (core_reg_sect, cor
*** 167,172 ****
    /* integer registers */
    memcpy (&registers[REGISTER_BYTE (0)], &core_reg->intreg,
  	  sizeof (struct reg));
    /* floating point registers */
!   /* XXX */
  }
--- 167,209 ----
    /* integer registers */
    memcpy (&registers[REGISTER_BYTE (0)], &core_reg->intreg,
  	  sizeof (struct reg));
+ 
    /* floating point registers */
!   RF (FP0_REGNUM,     core_reg->freg.regs[0]);
!   RF (FP0_REGNUM + 1, core_reg->freg.regs[1]);
!   RF (FP0_REGNUM + 2, core_reg->freg.regs[2]);
!   RF (FP0_REGNUM + 3, core_reg->freg.regs[3]);
!   RF (FP0_REGNUM + 4, core_reg->freg.regs[4]);
!   RF (FP0_REGNUM + 5, core_reg->freg.regs[5]);
!   RF (FP0_REGNUM + 6, core_reg->freg.regs[6]);
!   RF (FP0_REGNUM + 7, core_reg->freg.regs[7]);
! 
!   RF (FCTRL_REGNUM,   core_reg->freg.control);
!   RF (FSTAT_REGNUM,   core_reg->freg.status);
!   RF (FTAG_REGNUM,    core_reg->freg.tag);
!   RF (FCS_REGNUM,     core_reg->freg.code_seg);
!   RF (FCOFF_REGNUM,   core_reg->freg.eip);
!   RF (FDS_REGNUM,     core_reg->freg.operand_seg);
!   RF (FDOFF_REGNUM,   core_reg->freg.operand);
!   RF (FOP_REGNUM,     core_reg->freg.opcode);
! 
!   registers_fetched ();
! }
! 
! /* Register that we are able to handle i386nbsd core file formats.
!    FIXME: is this really bfd_target_unknown_flavour? */
! 
! static struct core_fns i386nbsd_core_fns =
! {
!   bfd_target_unknown_flavour,		/* core_flavour */
!   default_check_format,			/* check_format */
!   default_core_sniffer,			/* core_sniffer */
!   fetch_core_registers,			/* core_read_registers */
!   NULL					/* next */
! };
! 
! void
! _initialize_i386nbsd_nat ()
! {
!   add_core_fns (&i386nbsd_core_fns);
  }



-- 
J.T. Conklin
RedBack Networks
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Mark Kettenis <kettenis@wins.uva.nl>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: GDB-5 2000-03-03
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38C08FC8.CF5D627D@cygnus.com>
References: <38BFBD74.79263683@cygnus.com> <200003031714.e23HEC900400@delius.kettenis.local>
X-SW-Source: 2000-q1/msg00495.html
Content-length: 1683

Mark Kettenis wrote:

> There are two issue's in the generic x86 code that I'd like to
> address:

I've added these to the ``Nice to have'' section.  

> The current code doesn't run on Linux 2.x (remember the message you
> just sent to Tom):
> 
>    http://sourceware.cygnus.com/ml/gdb-patches/1999-q4/msg00294.html

Added.

> The FP control registers contain some really weird numbers since the
> reserved bits aren't masked of.  Patch:
> 
>    http://sourceware.cygnus.com/ml/gdb-patches/1999-q4/msg00375.html

Added.

> Signal tramplines aren't recognized.  Patch:
> 
>    http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00059.html

Added.

> Programs run under GDB have SIGCHLD masked.  No patch yet.

Added to ``nice to have''.  Can be worked around.

> This seems to happen on Solaris too.

Note added.


> This has been fixed:

Yes, I noticed that.  That's why I moved it to old problems :-)

> The testsuite runs OK, but contains a very limited number of tests.  I
> recently discovered that the thread_db code doesn't handle threads
> that exit.  See the following URL for more info:
> 
>    http://sourceware.cygnus.com/ml/gdb/2000-q1/msg00525.html
> 
> I would consider this a pretty critical bug.

I've added it (I can't comment on the seriousness of the specific bug).
More serious is the lack of proper testing of the thread code.  I'd
rather see effort put into improving the testsuite ready for 5.1 than
fixing bugs in 5.0.

>    Of course there is the issue of "which alpha release of glibc 2.1.3?".
>    Personally I (kingdon) am most worried about the one in Red Hat Linux
>    6.2beta.
> 
> There is an official glibc 2.1.3 release now.

Thanks,

	Andrew
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Stephane Carrez <Stephane.Carrez@worldnet.fr>
Cc: gdb-patches@sourceware.cygnus.com, Jim Blandy <jimb@cygnus.com>
Subject: Re: path for gdb/dwarf2read.c, support 16-bit targets in dwarf-2
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38BB5463.D6E5B75C@cygnus.com>
References: <38B2F3D3.54CF0AF0@worldnet.fr>
X-SW-Source: 2000-q1/msg00412.html
Content-length: 2194

Stephane Carrez wrote:
> 
> Hi!
> 
> The following patch fixes GDB dwarf-2 reader to support 16-bit address
> targets.
> 
> In 'dwarf2_build_psymtabs_hard' there was a hack to guess the size of the
> target address. We were using the bfd 'elf_size_info::arch_size' member.
> This corresponds to the ELF file arch size, not the target address size.
> I suggest to use 'bfd_arch_bits_per_address' which really corresponds to
> what we need.
> 
> Then, in 'read_address', we just have to read 2-bytes addresses.
> 
> I've been using this fix for a while with the 68HC11 port.
> 
> Can you integrate it?
> 
> Thanks,
>         Stephane
> 
> 2000-02-22  Stephane Carrez  <stcarrez@worldnet.fr>
> 
>         * dwarf2read.c (dwarf2_build_psymtabs_hard): Use
>         bfd_arch_bits_per_address to get the size of addresses.

FYI,

I've applied this bit:

>         (read_address): Read 16-bits addresses.

As for the change:

> -  address_significant_size = get_elf_backend_data (abfd)->s->arch_size / 8;
> +  address_significant_size = bfd_arch_bits_per_address (abfd) / 8;

I'm not so sure.  Does bfd_arch_bits_per_address() return 16 while the
elf data arch_size indicate something else (elf32 vs elf16?)

I've attatched some references to when a similar problem was discussed
for a 64 bit target with 32 bit ELF binaries.

Jim?

	Andrew

http://sourceware.cygnus.com/ml/gdb-patches/1999-q4/msg00267.html
http://sourceware.cygnus.com/ml/gdb-patches/1999-q4/msg00263.html
Tue Feb 29 15:14:56 2000  Andrew Cagney  <cagney@b1.cygnus.com>

	From 2000-02-22 Stephane Carrez <stcarrez@worldnet.fr>:
        * dwarf2read.c (read_address): Read 16-bits addresses.

Index: dwarf2read.c
===================================================================
RCS file: /cvs/src/src/gdb/dwarf2read.c,v
retrieving revision 1.2
diff -p -r1.2 dwarf2read.c
*** dwarf2read.c	2000/02/14 04:37:06	1.2
--- dwarf2read.c	2000/02/29 05:06:26
*************** read_address (abfd, buf)
*** 3487,3492 ****
--- 3487,3495 ----
  
    switch (address_size)
      {
+     case 2:
+       retval = bfd_get_16 (abfd, (bfd_byte *) buf);
+       break;
      case 4:
        retval = bfd_get_32 (abfd, (bfd_byte *) buf);
        break;
From kingdon@redhat.com Sat Apr 01 00:00:00 2000
From: Jim Kingdon <kingdon@redhat.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com, Jim Blandy <jimb@cygnus.com>
Subject: Re: path for gdb/dwarf2read.c, support 16-bit targets in dwarf-2
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <bput8j8vi.fsf@rtl.cygnus.com>
References: <38B2F3D3.54CF0AF0@worldnet.fr> <38BB5463.D6E5B75C@cygnus.com> <38C0D9D9.70987863@worldnet.fr> <38C225F3.9E236A55@cygnus.com>
X-SW-Source: 2000-q1/msg00539.html
Content-length: 1877

> When I say  ``elf16'', I was thinking of an elf object file that has 16
> bit addresses.  I'm not sure what other consequences such a move would
> have.

Strikes me as a bad idea.  Or to put it another way, designing a
hypothetical elf16 format seems like something you'd do only if you
had pretty compelling reasons, not just to fix a GDB bug which can be
fixed in much simpler ways.

> Is there any reason why s->arch_size isn't 16 in your case?

Hmm, that's an interesting question.  Some uses of arch_size in BFD
seem to decide alignment of pointers (in .got, .rela and other
sections in bfd/elflink.c) but others seem to be based on elf32
vs. elf64 (.stabsstr section in bfd/elf.c).  GDB doesn't seem to use
arch_size beyond the one usage we are discussing.  I didn't check
binutils.  I think it is possible that bfd/elflink.c should be
referring to bfd_arch_bits_per_address.

The whole address_significant_size code in dwarf2read.c strikes me as
a rather ugly kludge to work around bugs elsewhere in the tool chain.
If someone is supplying a 32 bit pointer to GDB on a 16 bit target,
shouldn't the rest of the tool chain be responsible for making sure
the high bits are zero rather than expecting GDB to mask it off?
Granted there might be complications here, like there are cases on
MIPS where we treat an address as signed rather than unsigned, but I'm
also pretty clear on whether that is actually design or just a bug.  I
could be wrong/persuadable, of course, and perhaps someone has a
better idea of all this (in which case I'd suggest commenting
arch_size at bfd/elf-bfd.h and/or expanding comments at
bfd_arch_bits_per_address in bfd/archures.c).

Or to put it another way, specifically what went wrong on the 68HC11
if you didn't change dwarf2read.c?  If it was just the "Dwarf Error:
bad address size" error, what happens if you just comment out that
check?
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Elena Zannoni <ezannoni@cygnus.com>
Cc: nsd@cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: Patch: catch_errors() bug fixes and speedups
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38B2FC43.DB202309@cygnus.com>
References: <200002112031.UAA02868@nog.bosbc.com> <200002222010.UAA05801@nog.bosbc.com> <14514.63567.180178.977613@kwikemart.cygnus.com>
X-SW-Source: 2000-q1/msg00308.html
Content-length: 279

Elena Zannoni wrote:
> 
> Looks great. Thanks Nick, for taking the time to fix this.
> It can certainly go in, unless Andrew has some objections.

Not likely.  catch_errors() always was a nasty piece of work.  This
cleanup makes it cleaner, faster, simpler.....

	nice,
		Andrew
From hjl@lucon.org Sat Apr 01 00:00:00 2000
From: "H . J . Lu" <hjl@lucon.org>
To: Jim Kingdon <kingdon@redhat.com>
Cc: toddpw@windriver.com, kettenis@wins.uva.nl, gdb-patches@sourceware.cygnus.com, gdb@sourceware.cygnus.com
Subject: Another revised patch for dlclose
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000308103740.A3530@lucon.org>
References: <200003080849.AAA18417@alabama.wrs.com> <200003081441.JAA02876@devserv.devel.redhat.com>
X-SW-Source: 2000-q1/msg00599.html
Content-length: 4624

On Wed, Mar 08, 2000 at 09:41:00AM -0500, Jim Kingdon wrote:
> 
> There are a few loose ends in freeing, but it is the tangled logic in
> find_solib that is tripping us up more than the freeing.

Here is a new patch. It seems to work with the testcase. Any
comments?


H.J.
----
2000-03-08  H.J. Lu  <hjl@gnu.org>

	Inspired by patches from Sam Lantinga (slouken@devolution.com):

	* solib.c (solib_verify): New function. Unload the shared
	object when it is deleted and dump symbols from the unloaded
	shared object.

	* solib.h (SOLIB_VERIFY): New. Defined as solib_verify.

	* infrun.c (handle_inferior_event): Also call SOLIB_VERIFY ()
	if it is defined when we hit the internal debug breakpoint for
	shared libraries in the dynamic linker.

Index: solib.c
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/solib.c,v
retrieving revision 1.1.1.4
retrieving revision 1.7
diff -u -p -r1.1.1.4 -r1.7
--- solib.c	2000/03/07 18:42:17	1.1.1.4
+++ solib.c	2000/03/08 18:36:11	1.7
@@ -950,6 +950,84 @@ open_symbol_file_object (arg)
   return 1;
 }
 #endif /* SVR4_SHARED_LIBS */
+
+/*
+  
+GLOBAL FUNCTION
+
+	solib_verify -- check solib list consistency and dump symbols
+			from unloaded shared objects
+
+SYNOPSIS
+
+	void solib_verify (void)
+
+DESCRIPTION
+
+	This module is called whenever we hit a dynamic linker
+	breakpoint and allows us to check the consistency of our shared 
+	object list and unload objects which are no longer valid in the
+	in the inferior. Without this, dynamic unlinking of objects
+	could crash us. This function should only be called when we
+	hit the internal debug breakpoint for shared libraries in the
+	dynamic linker.
+
+ */
+
+void
+solib_verify (void)
+{
+#ifdef SVR4_SHARED_LIBS
+  if (debug_base)
+    {
+      static int solib_unloading = 0;
+
+      read_memory (debug_base, (char *) &debug_copy,
+		   sizeof (struct r_debug));
+      if (debug_copy.r_state == RT_DELETE)
+        solib_unloading = 1;
+      else if (solib_unloading && debug_copy.r_state == RT_CONSISTENT)
+        {
+	  struct so_list *so = NULL, *next, *so_next, *saved;
+
+	  /* Get the current list of loaded shared libraries. */
+	  saved = so_list_head;
+	  so_list_head = NULL;
+	  while ((so = find_solib (so)) != NULL);
+	  so = so_list_head;
+	  so_list_head = saved;
+
+	  /* We compare the current list against what we have. */
+	  for (next = so_list_head; next; next = next->next)
+	    {
+	      for (so_next = so; so_next; so_next = so_next->next)
+	        if (strcmp (so_next->so_name, next->so_name) == 0)
+		  break;
+
+	      if (!so_next)
+	        {
+		  /* We didn't find it in the current list. Unload it.
+		     Since the dynamic linker can only unload one
+		     shared library at a time, we stop here. Also
+		     free_objfile () will call clear_solib (). It will
+		     clear everything for us.  */
+		  free_objfile (next->objfile);
+		  break;
+	        }
+	    }
+
+	  /* Free the current list of loaded shared libraries. */
+	  for (so_next = so; so_next; so_next = next)
+	    {
+	      next = so_next->next;
+	      free (so_next);
+	    }
+
+	  solib_unloading = 0;
+	}
+    }
+#endif	/* SVR4_SHARED_LIBS */
+}
 
 /*
 
Index: solib.h
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/solib.h,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -p -r1.1.1.1 -r1.2
--- solib.h	1999/09/09 00:38:38	1.1.1.1
+++ solib.h	2000/03/07 21:55:11	1.2
@@ -37,6 +37,14 @@ clear_solib PARAMS ((void));
 extern void
 solib_add PARAMS ((char *, int, struct target_ops *));
 
+/* Called to check solib list consistency and dump symbols from
+   unloaded shared objects. */
+
+#define SOLIB_VERIFY() solib_verify ()
+
+extern void
+solib_verify PARAMS ((void));
+
 /* Function to be called when the inferior starts up, to discover the names
    of shared libraries that are dynamically linked, the base addresses to
    which they are linked, and sufficient information to read in their symbols
Index: infrun.c
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/infrun.c,v
retrieving revision 1.1.1.6
retrieving revision 1.2
diff -u -p -r1.1.1.6 -r1.2
--- infrun.c	2000/03/07 18:42:13	1.1.1.6
+++ infrun.c	2000/03/07 21:55:11	1.2
@@ -2416,6 +2416,9 @@ handle_inferior_event (struct execution_
 		/* Switch terminal for any messages produced by
 		   breakpoint_re_set.  */
 		target_terminal_ours_for_output ();
+#ifdef SOLIB_VERIFY
+		SOLIB_VERIFY ();
+#endif
 		SOLIB_ADD (NULL, 0, NULL);
 		target_terminal_inferior ();
 	      }
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Jason Molenda <jsm@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: Patch to change gdb's behavior for Makefile target 'diststuff'
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38AA26ED.DAC914DC@cygnus.com>
References: <20000215200720.A20254@cygnus.com>
X-SW-Source: 2000-q1/msg00171.html
Content-length: 1603

Jason Molenda wrote:

Approved.

	Andrew

> I am trying to steal the binutils snapshot script.  That script does
> a 'make diststuff' at the top-level, which does all sorts of stuff.
> Diststuff in gdb does a 'all-doc' in the doc/ subdirectory and the
> Makefile there tries to run tex to generate some DVI files.
> 
> I want gdb/Makefile.in to run 'diststuff' in the doc/ directory, and
> I want 'diststuff' in the doc/ directory to just generate the info
> files.
> 
> This mirrors the binutils behavior.
> 
> Jason
> 
> Index: Makefile.in
> ===================================================================
> RCS file: /cvs/src/src/gdb/Makefile.in,v
> retrieving revision 1.3
> diff -u -p -r1.3 Makefile.in
> --- Makefile.in 2000/02/09 08:52:44     1.3
> +++ Makefile.in 2000/02/16 04:03:49
> @@ -872,7 +872,7 @@ do-maintainer-clean:
>                 subdir_do
> 
>  diststuff: $(DISTSTUFF)
> -       cd doc; $(MAKE) $(MFLAGS) all-doc
> +       cd doc; $(MAKE) $(MFLAGS) diststuff
> 
>  subdir_do: force
>         @for i in $(DODIRS); do \
> Index: doc/Makefile.in
> ===================================================================
> RCS file: /cvs/src/src/gdb/doc/Makefile.in,v
> retrieving revision 1.1.1.5
> diff -u -p -r1.1.1.5 Makefile.in
> --- Makefile.in 2000/02/07 00:19:39     1.1.1.5
> +++ Makefile.in 2000/02/16 04:03:53
> @@ -100,6 +100,7 @@ dvi: gdb.dvi gdbint.dvi stabs.dvi refcar
>  ps: gdb.ps gdbint.ps stabs.ps refcard.ps
>  html: gdb_toc.html gdbint_toc.html stabs_toc.html
>  all-doc: info dvi ps
> +diststuff: info
> 
>  install-info: info
>         for i in *.info* ; do \
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: jtc@redback.com
Cc: Kevin Buettner <kevinb@cygnus.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH] Minor change to gdb/doc/agentexpr.texi
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38AC8B93.6A1F0028@cygnus.com>
References: <1000216043742.ZM2605@ocotillo.lan> <5mk8k3tv6h.fsf@jtc.redbacknetworks.com>
X-SW-Source: 2000-q1/msg00235.html
Content-length: 820

"J.T. Conklin" wrote:
> 
> >>>>> "Kevin" == Kevin Buettner <kevinb@cygnus.com> writes:
> Kevin> I've just committed a minor change (see below) to
> Kevin> gdb/doc/agentexpr.texi.  Intel does not want us to use "Merced"
> Kevin> in the gdb documentation.  And when referring to their next
> Kevin> generation architecture, we must use "IA-64".  No other variant
> Kevin> is acceptable.
> 
> I have no problem with the change per se, but the implication that
> some other party can dictate what is, and what is not, "acceptable"
> to put in FSF manuals is disturbing.

In this case, while I think it is important I dont think it is a
concern.  Where a tradmark name is used in a published document it
should be used correctly.

(Unless of course the FSF has some policy where it refuses to recognize
trademarks.)

	Andrew
From kettenis@wins.uva.nl Sat Apr 01 00:00:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: eliz@is.elta.co.il
Cc: jimb@zwingli.cygnus.com, kevinb@cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: Linux sigtramp detection code moved to its proper place
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003201214.e2KCEYK00493@delius.kettenis.local>
References: <200003162241.RAA19616@zwingli.cygnus.com> <1000316225504.ZM3009@ocotillo.lan> <npsnxp8ix6.fsf@zwingli.cygnus.com> <200003182227.RAA07058@indy.delorie.com> <200003192248.e2JMm1H00626@delius.kettenis.local> <200003201002.FAA09374@indy.delorie.com>
X-SW-Source: 2000-q1/msg00813.html
Content-length: 1004

   Date: Mon, 20 Mar 2000 05:02:58 -0500 (EST)
   From: Eli Zaretskii <eliz@delorie.com>

   >    How about i386linux-tdep.c, for example?
   > 
   > Yuck, that's ugly!

   How is it uglier than i386gnu-nat.c?

I want either i386-linux-nat.c and i386-linux-tdep.c or
i386linux-nat.c and i386linux-tdep.c, but *not* a mixture of those.
If I ever see the need for target dependent code for the Hurd/i386 it
will end up in i386gnu-tdep.c (which isn't 8.3 unique either).

   > 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.

   What would you suggest for a non-buggy Tar program to do, exactly?

Simply overwrite the files, possibly asking confirmation from the
user.  This shouldn't be a problem, since the DJGPP native port
doesn't need i386-linux-nat.c nor i386-linux-tdep.c.

Mark
From kevinb@cygnus.com Sat Apr 01 00:00:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Cc: Michael Snyder <msnyder@cygnus.com>
Subject: [PATCH RFA] linux-thread.c, lin-thread.c changes
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <1000324204825.ZM4807@ocotillo.lan>
X-SW-Source: 2000-q1/msg00996.html
Content-length: 2748

I request approval for committing the changes below.

The lines that read

    #if TARGET_PTR_BIT > TARGET_INT_BIT

cause a compilation error on linux/ia64 due to the fact that
TARGET_PTR_BIT and TARGET_INT_BIT are computed at runtime for the
IA-64 architecture.  (When we get around to multi-arching the other
linux ports, they'll have the same problem.)

	* linux-thread.c, lin-thread.c (save_inferior_pid,
	restore_inferior_pid): Don't do compile time comparison
	of TARGET_PTR_BIT and TARGET_INT_BIT.

Index: linux-thread.c
===================================================================
RCS file: /cvs/src/src/gdb/linux-thread.c,v
retrieving revision 1.5
diff -u -p -r1.5 linux-thread.c
--- linux-thread.c	2000/03/18 01:56:31	1.5
+++ linux-thread.c	2000/03/24 20:36:43
@@ -378,25 +378,22 @@ linuxthreads_find_trap (pid, stop)
 
 /* Cleanup stub for save_inferior_pid.  */
 static void
-restore_inferior_pid (arg)
-    void *arg;
+restore_inferior_pid (void *arg)
 {
-#if TARGET_PTR_BIT > TARGET_INT_BIT
-  inferior_pid = (int) ((long) arg);
-#else
-  inferior_pid = (int) arg;
-#endif
+  int *saved_pid_ptr = arg;
+  inferior_pid = *saved_pid_ptr;
+  free (arg);
 }
 
 /* Register a cleanup to restore the value of inferior_pid.  */
 static struct cleanup *
-save_inferior_pid ()
+save_inferior_pid (void)
 {
-#if TARGET_PTR_BIT > TARGET_INT_BIT
-  return make_cleanup (restore_inferior_pid, (void *) ((long) inferior_pid));
-#else
-  return make_cleanup (restore_inferior_pid, (void *) inferior_pid);
-#endif
+  int *saved_pid_ptr;
+  
+  saved_pid_ptr = xmalloc (sizeof (int));
+  *saved_pid_ptr = inferior_pid;
+  return make_cleanup (restore_inferior_pid, saved_pid_ptr);
 }
 
 static void
Index: lin-thread.c
===================================================================
RCS file: /cvs/src/src/gdb/lin-thread.c,v
retrieving revision 1.2
diff -u -p -r1.2 lin-thread.c
--- lin-thread.c	2000/02/09 08:52:46	1.2
+++ lin-thread.c	2000/03/24 20:36:47
@@ -658,21 +658,19 @@ init_thread_db_library ()
 static struct cleanup *
 save_inferior_pid (void)
 {
-#if TARGET_PTR_BIT > TARGET_INT_BIT
-  return make_cleanup (restore_inferior_pid, (void *) ((long) inferior_pid));
-#else
-  return make_cleanup (restore_inferior_pid, (void *) inferior_pid);
-#endif
+  int *saved_pid_ptr;
+  
+  saved_pid_ptr = xmalloc (sizeof (int));
+  *saved_pid_ptr = inferior_pid;
+  return make_cleanup (restore_inferior_pid, saved_pid_ptr);
 }
 
 static void
-restore_inferior_pid (void *saved_pid)
+restore_inferior_pid (void *arg)
 {
-#if TARGET_PTR_BIT > TARGET_INT_BIT
-  inferior_pid = (int) ((long) saved_pid);
-#else
-  inferior_pid = (int) saved_pid;
-#endif
+  int *saved_pid_ptr = arg;
+  inferior_pid = *saved_pid_ptr;
+  free (arg);
 }
 
 /*