Re: RFA: gdbarch_free

[Andrew Cagney <ac131313@cygnus.com>]

Jim Blandy wrote:
> 
> There are no uses for this yet, except in some code that's not ready
> for release yet.
> 
> 2000-02-28  Jim Blandy  <jimb@redhat.com>
> 
>         * gdbarch.sh: Emit a definition and declaration for gdbarch_free,
>         a companion to gdbarch_alloc, which allows a gdbarch init function
>         to free partially-built gdbarch structures.
>         * gdbarch.c, gdbarch.h: Regenerated.

Jim,

Can you expand a little.

From memory, I figured that if an _initialize* function failed to create
a gdbarch the process was somewhat hosed and calling internal_error()
was probably the best thing to do.

	Andrew
From ac131313@cygnus.com Mon Feb 28 18:08:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: Please ``withdraw'' patches
Date: Mon, 28 Feb 2000 18:08:00 -0000
Message-id: <38BB29FF.2467FCE@cygnus.com>
X-SW-Source: 2000-02/msg00061.html
Content-length: 449

Hello,

I've just spent an hour going over a patch (yes I'm working through a
long backlog) only to then find a later submission by the same author
supersedes the earlier posting.

If people withdraw or re-submit patches, could they please to a follow
up to the original posting making it clear that that submission was
withdrawn.

	enjoy,
		Andrew

(Hopefully a patch tracking system will help with this problem (although
it may not eliminate it))
From ac131313@cygnus.com Mon Feb 28 18:23:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Fernando Nasser <fnasser@cygnus.com>
Cc: gdb-patches@sourceware.cygnus.com, Elena Zannoni <ezannoni@cygnus.com>
Subject: Re: RFA: Patch to blockframe.c, frame.h, arm-tdep.c and fr30-tdep.c (prologue cache)
Date: Mon, 28 Feb 2000 18:23:00 -0000
Message-id: <38BB2D7D.4081A59B@cygnus.com>
References: <38ACA4D6.993AFF74@cygnus.com>
X-SW-Source: 2000-02/msg00062.html
Content-length: 1412

Fernando Nasser wrote:
> 
> I believe the following fixes a bug found by Elena.
> 
> Fernando
> 
> 2000-02-17  Fernando Nasser  <fnasser@totem.to.cygnus.com>
> 
>         * blockframe.c (check_prologue_cache, save_prologue_cache,
>         flush_prologue_cache): Slightly improved version of a prologue
> cache
>         used by some targets. Here there is a flush mechanism so we
> never use
>         stale data.
>         * frame.h: Prototypes for the above functions.
>         * arm-tdep.c (check_prologue_cache, save_prologue_cache):
> Deleted.
>         Moved (with changes) to blockframe.c.

First a technical question:  Does the code work with targets with
EXTRA_FRAME_INFO and INIT_EXTRA_FRAME_INFO?  I'm not sure if that should
be saved or not?

At a less technical level I also encountered the following problems:

	o	The function flush_prologue_cache()
		is called as flush_prolog_cache().
		As it stands, the patch won't compile.

	o	the change to frame.h creates
		``extern static ... PARAMS (())''

		The PARAMS bit isn't necessary
		and I suspect the ``extern static''
		was a cut/paste mistake.

		The header should also briefly
		explain what the interface is.

	o	the file fr30-tdep.c was changed
		but the ChangeLog didn't mention it

	o	btw your mail tool corrupted the
		patch (splitting several lines)

	o	I'd recommend making the FI param
		to save_prologue_cache const.

sorry,
	Andrew
From ac131313@cygnus.com Mon Feb 28 21:10: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: Mon, 28 Feb 2000 21:10:00 -0000
Message-id: <38BB5463.D6E5B75C@cygnus.com>
References: <38B2F3D3.54CF0AF0@worldnet.fr>
X-SW-Source: 2000-02/msg00063.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 ac131313@cygnus.com Mon Feb 28 21:49:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: tromey@cygnus.com
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: Patch: make "!" a command unconditionally
Date: Mon, 28 Feb 2000 21:49:00 -0000
Message-id: <38BB5D9F.1A9BF1B3@cygnus.com>
References: <87itz9cabi.fsf@cygnus.com>
X-SW-Source: 2000-02/msg00064.html
Content-length: 1214

Tom Tromey wrote:
> 
> I'd like "!" to be an unconditional alias for "shell".
> Here is a patch.
> 
> 2000-02-28  Tom Tromey  <tromey@cygnus.com>
> 
>         * command.c (_initialize_command): Make "!" alias
>         unconditionally.
> 
> Tom
> 
> Index: command.c
> ===================================================================
> RCS file: /cvs/cvsfiles/devo/gdb/command.c,v
> retrieving revision 1.65
> diff -u -r1.65 command.c
> --- command.c   2000/02/09 08:53:11     1.65
> +++ command.c   2000/02/28 20:57:08
> @@ -1678,8 +1678,7 @@
>            "Execute the rest of the line as a shell command.  \n\
>  With no arguments, run an inferior shell.");
> 
> -  if (xdb_commands)
> -    add_com_alias ("!", "shell", class_support, 0);
> +  add_com_alias ("!", "shell", class_support, 0);
> 
>    add_com ("make", class_support, make_command,
>         "Run the ``make'' program using the rest of the line as arguments.");

From memory this has been suggested before.  The problem pointed out
last time was that you need to specify:

	``!'' <space> <command>

I think there also may have been a debate over ``!'' as a shell escape
vs ``!'' for history.
(personally it didn't worry me).  Fernando?

	Andrew
From ac131313@cygnus.com Mon Feb 28 22:25:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Fernando Nasser <fnasser@redhat.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: RFA: Prologue cache fix
Date: Mon, 28 Feb 2000 22:25:00 -0000
Message-id: <38BB65F6.44D991A2@cygnus.com>
References: <38B4073E.281C4CE0@redhat.com>
X-SW-Source: 2000-02/msg00065.html
Content-length: 1434

Fernando Nasser wrote:
> 
> This patch fixes a problem that happens when gdb reconnects to a
> target.  Targets that have a prologue cache must invalidate its contents
> or they can assume wrong things based on stale data.

I'm wondering when exactly this prologue_cache provides real benefit?

If the prologue_cache is purged at the same time as the frame obstack
then the two have the same lifetime.  If that is the case then I think
that the prologue analysis might as well be left in the frame object in
``struct frame_extra_info''.

The only other possibility I can think of is is something like an
inferior function call where GDB comes back to that exact same address. 
For a recursive call, the register info would be wrong.

So anyone enlighten me as to when exactly this thing kicks in? :-)

> 2000-02-23  Fernando Nasser  <fnasser@totem.to.cygnus.com>
> 
>         * gdbint.texinfo: Add entry for target dependent macro
>         FLUSH_PROLOGUE_CACHE.

> *** blockframe.c        1999/12/22 21:45:03     1.1.1.11
> --- blockframe.c        2000/02/23 00:17:15
> *************** flush_cached_frames ()
> *** 269,274 ****
> --- 269,277 ----
> 
>     current_frame = NULL;               /* Invalidate cache */
>     select_frame (NULL, -1);
> + #ifdef FLUSH_PROLOGUE_CACHE
> +   FLUSH_PROLOGUE_CACHE ();
> + #endif
>     annotate_frames_invalid ();
>   }
>

As an asside, this won't work well with multi-arch.

	enjoy,
		Andrew
From ac131313@cygnus.com Mon Feb 28 23:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Fernando Nasser <fnasser@redhat.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: RFC: Frame cache s not always available.
Date: Mon, 28 Feb 2000 23:00:00 -0000
Message-id: <38BB6E31.203DD244@cygnus.com>
References: <38B40EB5.E9503E1C@redhat.com>
X-SW-Source: 2000-02/msg00066.html
Content-length: 2531

Fernando Nasser wrote:
> 
> We are starting to talk about situations where the frames should not
> considered valid.  For some oversighting, or maybe because it is
> gradually being implemented, gdb only tests for the return value of
> get_current_frame() in one place and assumes in several places that
> selected_frame is set.
> 
> I found two places that are more troublesome and created the attached
> patch.  I did implement the frame invalid situation in the arm target
> (on my sandbox only) and this two changes alone were enough.  We may
> found a few others in the future, and the situation were we do not have
> a current or selected frame are not checked in yet, but I believe we
> should make the code more robust and check this patch in anyway.

FYI,

I applied the attatched.

	Andrew
Tue Feb 29 17:33:49 2000  Andrew Cagney  <cagney@b1.cygnus.com>

	From Wed, 23 Feb 2000 Fernando Nasser <fnasser@redhat.com>:
	* stack.c (backtrace_command_1), infrun.c (normal_stop): Check
 	that the target's stack was valid.

Index: infrun.c
===================================================================
RCS file: /cvs/src/src/gdb/infrun.c,v
retrieving revision 1.3
diff -p -r1.3 infrun.c
*** infrun.c	2000/02/23 00:25:42	1.3
--- infrun.c	2000/02/29 06:54:55
*************** The same program may be running in anoth
*** 3429,3435 ****
           bpstat_print() contains the logic deciding in detail
           what to print, based on the event(s) that just occurred. */
  
!       if (stop_print_frame)
  	{
  	  int bpstat_ret;
  	  int source_flag;
--- 3429,3436 ----
           bpstat_print() contains the logic deciding in detail
           what to print, based on the event(s) that just occurred. */
  
!       if (stop_print_frame
! 	  && selected_frame)
  	{
  	  int bpstat_ret;
  	  int source_flag;
Index: stack.c
===================================================================
RCS file: /cvs/src/src/gdb/stack.c,v
retrieving revision 1.2
diff -p -r1.2 stack.c
*** stack.c	2000/02/08 04:39:02	1.2
--- stack.c	2000/02/29 06:55:00
*************** backtrace_command_1 (count_exp, show_loc
*** 1111,1116 ****
--- 1111,1122 ----
       printing.  Second, it must set the variable count to the number
       of frames which we should print, or -1 if all of them.  */
    trailing = get_current_frame ();
+ 
+   /* The target can be in a state where there is no valid frames
+      (e.g., just connected). */
+   if (trailing == NULL)
+     error ("No stack.");
+ 
    trailing_level = 0;
    if (count_exp)
      {
From tromey@cygnus.com Mon Feb 28 23:01:00 2000
From: Tom Tromey <tromey@cygnus.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: tromey@cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: Patch: make "!" a command unconditionally
Date: Mon, 28 Feb 2000 23:01:00 -0000
Message-id: <200002290701.XAA15591@ferrule.cygnus.com>
References: <87itz9cabi.fsf@cygnus.com> <38BB5D9F.1A9BF1B3@cygnus.com>
X-SW-Source: 2000-02/msg00067.html
Content-length: 734

>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:

Andrew> From memory this has been suggested before.  The problem pointed out
Andrew> last time was that you need to specify:

Andrew> 	``!'' <space> <command>

I suggested it last time but didn't supply a patch.
I agree it would be nice to eliminate the space.
That's probably more than a 20 second hack though :-(

Andrew> I think there also may have been a debate over ``!'' as a
Andrew> shell escape vs ``!'' for history.  (personally it didn't
Andrew> worry me).  Fernando?

This doesn't bother me either.  For these kinds of tools "!" is more
typically a shell escape.

Speaking of history, I wish gdb would pick up bash's "C-o"
(operate-and-get-next) binding.

Tom
From ac131313@cygnus.com Mon Feb 28 23:03:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: dan@cgsoftware.com
Cc: Fernando Nasser <fnasser@redhat.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: RFC: Frame cache s not always available.
Date: Mon, 28 Feb 2000 23:03:00 -0000
Message-id: <38BB6EBB.6F565574@cygnus.com>
References: <38B40EB5.E9503E1C@redhat.com> <bt57svje.fsf@dan.resnet.rochester.edu>
X-SW-Source: 2000-02/msg00068.html
Content-length: 1413

Daniel Berlin wrote:
> 
> >>>>> "FN" == Fernando Nasser <fnasser@redhat.com> writes:
> 
>    FN> considered valid.  For some oversighting, or maybe because it is
>    FN> gradually being implemented, gdb only tests for the return value of
>    FN> get_current_frame() in one place and assumes in several places that
>    FN> selected_frame is set.
> 
>    FN> I found two places that are more troublesome and created the attached
>    FN> patch.  I did implement the frame invalid situation in the arm target
>    FN> (on my sandbox only) and this two changes alone were enough.  We may
>    FN> found a few others in the future, and the situation were we do not
>    FN> have a current or selected frame are not checked in yet, but I believe
>    FN> we should make the code more robust and check this patch in anyway.
> 
> I've found a few places in the code as well where the frame is invalid
> because we switched threads.
> I had to manually force gdb to reinit the frame cache, or else we wouldn't
> have the right frames.
> 
> However, i believe this may be a side effect of the way the beos port is
> done, so i have them #ifdef'd for BEOS.
> Just wanted to throw this out in case someone was working with threads and
> saw incorrect stack backtraces.
> --Dan

I'd suspect that it was a bug.
Must likely the reason it hasn't been noticed is that BE goes places
where other OS's fear to tread :-)

	Andrew
From ac131313@cygnus.com Mon Feb 28 23:08:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Jim Kingdon <kingdon@redhat.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: RFC: Frame cache s not always available.
Date: Mon, 28 Feb 2000 23:08:00 -0000
Message-id: <38BB6FBE.6261782D@cygnus.com>
References: <38B40EB5.E9503E1C@redhat.com> <b4sav691t.fsf@rtl.cygnus.com>
X-SW-Source: 2000-02/msg00069.html
Content-length: 414

Jim Kingdon wrote:

> 
> I don't see problems with this patch, except that I think I'd change
> "No stack." to "No frames.".  The former could be pretty confusing
> since it also means things like "there is no memory which GDB knows
> about".

Turns out that everywhere else ``No Stack.'' was being used.
(Besides, no-frames makes me think of web pages - is there a web browser
in GDBtk yet? :-)

	enjoy,
		Andrew
From ac131313@cygnus.com Mon Feb 28 23:22:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: fernando@cygnus.com
Cc: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: [PATCH] Include <ctype.h> in arm-tdep.c
Date: Mon, 28 Feb 2000 23:22:00 -0000
Message-id: <38BB738C.ED57ED7C@cygnus.com>
X-SW-Source: 2000-02/msg00070.html
Content-length: 682

FYI,

I've applied the attatched.

	Andrew
Tue Feb 29 18:09:46 2000  Andrew Cagney  <cagney@b1.cygnus.com>

	* arm-tdep.c: Include <ctype.h>.

Index: arm-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/arm-tdep.c,v
retrieving revision 1.3
diff -p -r1.3 arm-tdep.c
*** arm-tdep.c	2000/02/17 19:51:04	1.3
--- arm-tdep.c	2000/02/29 07:18:29
***************
*** 28,33 ****
--- 28,34 ----
  #include "gdb_string.h"
  #include "coff/internal.h"	/* Internal format of COFF symbols in BFD */
  #include "dis-asm.h"		/* For register flavors. */
+ #include <ctype.h>		/* for isupper () */
  
  extern void _initialize_arm_tdep (void);
  
From ac131313@cygnus.com Mon Feb 28 23:46:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Eli Zaretskii <eliz@delorie.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH] Some compiler warnings removed
Date: Mon, 28 Feb 2000 23:46:00 -0000
Message-id: <38BB78FF.FBD9A73D@cygnus.com>
References: <200002232235.RAA18817@indy.delorie.com>
X-SW-Source: 2000-02/msg00071.html
Content-length: 5652

Eli Zaretskii wrote:
> 
> Here's my share of shutting up "gcc -Wall -W".  Is "foo = foo;" an
> okay solution for unused argument foo?
> 
> These diffs are against Feb 17 snapshot.  I hope they are still
> relevant and apply cleanly.
> 
> 2000-02-23  Eli Zaretskii  <eliz@is.elta.co.il>
> 
>         * utils.c [__GO32__]: Include pc.h, for prototypes of ScreenCols
>         and ScreenRows.
> 
>         * ser-go32.c: Include string.h, for prototype of strncasecmp.
>         (dpmi_regs, dpmi_sregs): Remove unused variables.
>         (dos_flush_input): Return a value, to prevent compiler warning.
> 
>         * main.c (captured_command_loop): Prevent gcc from complaining
>         about unused argument.
> 
>         * gdbtypes.c (count_virtual_fns): Make sure vfuncs is initialized
>         to zero.
> 
>         * expprint.c (dump_prefix_expression): Use %ld in format and cast
>         sizeof(union exp_element) to long, to prevent GCC from complaining
>         about format/argument mismatch.
>         (dump_postfix_expression): Likewise.
> 
>         * blockframe.c (nonnull_frame_chain_valid)
>         (pc_in_call_dummy_before_text_end)
>         (pc_in_call_dummy_after_text_end)
>         (pc_in_call_dummy_at_entry_point, generic_pc_in_call_dummy):
>         Prevent gcc from complaining about unused arguments.

FYI,  I pruned it back a bit and applied the attatched.  Now if someone
would just change gcc :-)

	Andrew
Tue Feb 29 18:40:08 2000  Andrew Cagney  <cagney@b1.cygnus.com>

	From 2000-02-23 Eli Zaretskii <eliz@is.elta.co.il>:
	* utils.c [__GO32__]: Include pc.h, for prototypes of ScreenCols
	and ScreenRows.
	* ser-go32.c: Include string.h, for prototype of strncasecmp.
	(dpmi_regs, dpmi_sregs): Remove unused variables.
	(dos_flush_input): Return a value, to prevent compiler warning.
	* expprint.c (dump_prefix_expression): Use %ld in format and cast
	sizeof(union exp_element) to long, to prevent GCC from complaining
	about format/argument mismatch.
	(dump_postfix_expression): Likewise.

Index: expprint.c
===================================================================
RCS file: /cvs/src/src/gdb/expprint.c,v
retrieving revision 1.1.1.6
diff -p -r1.1.1.6 expprint.c
*** expprint.c	2000/02/02 00:21:06	1.1.1.6
--- expprint.c	2000/02/29 07:39:25
*************** dump_prefix_expression (exp, stream, not
*** 710,718 ****
      print_expression (exp, stream);
    else
      fprintf_filtered (stream, "Type printing not yet supported....");
!   fprintf_filtered (stream, "'\n\tLanguage %s, %d elements, %d bytes each.\n",
  		    exp->language_defn->la_name, exp->nelts,
! 		    sizeof (union exp_element));
    fprintf_filtered (stream, "\t%5s  %20s  %16s  %s\n", "Index", "Opcode",
  		    "Hex Value", "String Value");
    for (elt = 0; elt < exp->nelts; elt++)
--- 710,718 ----
      print_expression (exp, stream);
    else
      fprintf_filtered (stream, "Type printing not yet supported....");
!   fprintf_filtered (stream, "'\n\tLanguage %s, %d elements, %ld bytes each.\n",
  		    exp->language_defn->la_name, exp->nelts,
! 		    (long) sizeof (union exp_element));
    fprintf_filtered (stream, "\t%5s  %20s  %16s  %s\n", "Index", "Opcode",
  		    "Hex Value", "String Value");
    for (elt = 0; elt < exp->nelts; elt++)
*************** dump_postfix_expression (exp, stream, no
*** 986,994 ****
      print_expression (exp, stream);
    else
      fputs_filtered ("Type printing not yet supported....", stream);
!   fprintf_filtered (stream, "'\n\tLanguage %s, %d elements, %d bytes each.\n",
  		    exp->language_defn->la_name, exp->nelts,
! 		    sizeof (union exp_element));
    fputs_filtered ("\n", stream);
  
    for (elt = 0; elt < exp->nelts;)
--- 986,994 ----
      print_expression (exp, stream);
    else
      fputs_filtered ("Type printing not yet supported....", stream);
!   fprintf_filtered (stream, "'\n\tLanguage %s, %d elements, %ld bytes each.\n",
  		    exp->language_defn->la_name, exp->nelts,
! 		    (long) sizeof (union exp_element));
    fputs_filtered ("\n", stream);
  
    for (elt = 0; elt < exp->nelts;)
Index: ser-go32.c
===================================================================
RCS file: /cvs/src/src/gdb/ser-go32.c,v
retrieving revision 1.1.1.5
diff -p -r1.1.1.5 ser-go32.c
*** ser-go32.c	2000/02/02 00:21:10	1.1.1.5
--- ser-go32.c	2000/02/29 07:39:27
***************
*** 127,141 ****
  #define	MSR_DDSR	0x02
  #define	MSR_DCTS	0x01
  
  #include <dos.h>
  #include <go32.h>
  #include <dpmi.h>
  typedef unsigned long u_long;
  
- /* DPMI Communication */
- static union REGS dpmi_regs;
- static struct SREGS dpmi_sregs;
- 
  /* 16550 rx fifo trigger point */
  #define FIFO_TRIGGER	FIFO_TRIGGER_4
  
--- 127,138 ----
  #define	MSR_DDSR	0x02
  #define	MSR_DCTS	0x01
  
+ #include <string.h>
  #include <dos.h>
  #include <go32.h>
  #include <dpmi.h>
  typedef unsigned long u_long;
  
  /* 16550 rx fifo trigger point */
  #define FIFO_TRIGGER	FIFO_TRIGGER_4
  
*************** dos_flush_input (scb)
*** 693,698 ****
--- 690,696 ----
    if (port->fifo)
      outb (port, com_fifo, FIFO_ENABLE | FIFO_RCV_RST | FIFO_TRIGGER);
    enable ();
+   return 0;
  }
  
  static void
Index: utils.c
===================================================================
RCS file: /cvs/src/src/gdb/utils.c,v
retrieving revision 1.1.1.26
diff -p -r1.1.1.26 utils.c
*** utils.c	2000/02/02 00:21:11	1.1.1.26
--- utils.c	2000/02/29 07:39:34
***************
*** 31,36 ****
--- 31,40 ----
  #include <term.h>
  #endif
  
+ #ifdef __GO32__
+ #include <pc.h>
+ #endif
+ 
  /* SunOS's curses.h has a '#define reg register' in it.  Thank you Sun. */
  #ifdef reg
  #undef reg
From ac131313@cygnus.com Tue Feb 29 00:03:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Eli Zaretskii <eliz@delorie.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH]: DJGPP build and cleanup
Date: Tue, 29 Feb 2000 00:03:00 -0000
Message-id: <38BB7BDD.39EEFE54@cygnus.com>
References: <200002232229.RAA18809@indy.delorie.com>
X-SW-Source: 2000-02/msg00072.html
Content-length: 851

Eli Zaretskii wrote:

> 2000-02-23  Eli Zaretskii  <eliz@is.elta.co.il>
> 
>         * config/i386/nm-go32.h (FLOAT_INFO): Remove macro definition.
>         (top level): Add prototypes for go32_* functions.
> 
>         * config/i386/tm-go32.h (I386_DJGPP_TARGET): Define.
>         (FRAME_CHAIN, FRAMELESS_FUNCTION_INVOCATION, FRAME_SAVED_PC):
>         Override definitions from tm-i386.h.
>         (REGISTER_VIRTUAL_TYPE): Remove macro definition.
> 
>         * 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.

FYI,

I've checked this in.  The only mod I made was to add a FIXME to
i386_extract_return_value() pointing out that the function should be
multi-arched.

Hope it matches what you had,

	Andrew
From Peter.Schauer@regent.e-technik.tu-muenchen.de Tue Feb 29 01:23:00 2000
From: "Peter.Schauer" <Peter.Schauer@regent.e-technik.tu-muenchen.de>
To: gdb-patches@sourceware.cygnus.com
Subject: Re: Patches to add i387 support to Solaris x86 platforms (withdrawn)
Date: Tue, 29 Feb 2000 01:23:00 -0000
Message-id: <200002290923.KAA07207@reisser.regent.e-technik.tu-muenchen.de>
References: <200002240845.JAA27280@reisser.regent.e-technik.tu-muenchen.de>
X-SW-Source: 2000-02/msg00073.html
Content-length: 175

These patches are withdrawn, they are superseded by
http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00398.html

-- 
Peter Schauer			pes@regent.e-technik.tu-muenchen.de
From ac131313@cygnus.com Tue Feb 29 05:01:00 2000
From: Andrew Cagney <ac131313@cygnus.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: Tue, 29 Feb 2000 05:01:00 -0000
Message-id: <38BBC28D.D11E522C@cygnus.com>
References: <200002232157.WAA26169@reisser.regent.e-technik.tu-muenchen.de>
X-SW-Source: 2000-02/msg00074.html
Content-length: 435

"Peter.Schauer" wrote:
> 
> 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:
> 
> 2000-02-23  Peter Schauer  <pes@regent.e-technik.tu-muenchen.de>
> 
>         * objfiles.c (open_mapped_file):  Fix obsolete references to `mapped'
>         parameter.
> 
I've checked this in.

	thanks!
		Andrew
From ac131313@cygnus.com Tue Feb 29 05:31:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: jtc@redback.com
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: PATCH: update i386 port to use FRAME_INIT_SAVED_REGS()
Date: Tue, 29 Feb 2000 05:31:00 -0000
Message-id: <38BBC9F6.E847B7F@cygnus.com>
References: <5mbt5vrxxp.fsf@jtc.redbacknetworks.com>
X-SW-Source: 2000-02/msg00075.html
Content-length: 1450

"J.T. Conklin" wrote:
> 
> Moving the master GDB repository to sourceware provided the motivation
> for me to sync up to the most recent snapshots, compare my repository,
> and try to minimize the divergence.  Easier than finishing the memory
> region attribute code...
> 
> Most of these are patches that have been submitted before but were not
> rejected.
> 
> >From the original submission: "I made this change a while ago, back
> when Andrew was making similar changes to other targets.  It's been in
> my sources for some time, I found it again when I was checking the
> differences between my repository and the last snapshot."
> 
> The enclosed ChangeLog is from the original message.  The patch is
> relative to the 20000204 snapshot.
> 
>         --jtc
> 
> 1999-08-13  J.T. Conklin  <jtc@redback.com>
> 
>         * config/i386/tm-i386.h (FRAME_INIT_SAVED_REGS): Replace
>         FRAME_FIND_SAVED_REGS.
>         (i386_frame_init_saved_regs): Replace i386_frame_find_saved_regs.
>         * i386-tdep.c (i386_frame_init_saved_regs, i386_pop_frame):
>         Update.

FYI,

I've checked this in. (And run basic checks on an NetBSD/i386 machine). 
All the */i386 maintainers should make a mental note (but I don't expect
problems).

Other non i386 maintainers should also think about doing this conversion
the next time they go to tidy up their target.  It's about the hardest
thing to fix when wanting to use any multi-arch code.

	Andrew
From ac131313@cygnus.com Tue Feb 29 05:41:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: "Peter.Schauer" <Peter.Schauer@regent.e-technik.tu-muenchen.de>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: Patch to fix thread support for Solaris x86
Date: Tue, 29 Feb 2000 05:41:00 -0000
Message-id: <38BBCC0E.8EBC301A@cygnus.com>
References: <200002261228.NAA32377@reisser.regent.e-technik.tu-muenchen.de>
X-SW-Source: 2000-02/msg00076.html
Content-length: 478

"Peter.Schauer" wrote:
> 
> This patch fixes thread support for Solaris x86 platforms.
> 
> The patch gets rid of the following testsuite fail and causes no regressions:
> FAIL: gdb.threads/pthreads.exp: continue to bkpt at common_routine in thread 2
> 
> 2000-02-26  Peter Schauer  <pes@regent.e-technik.tu-muenchen.de>
> 
>         * config/i386/tm-i386sol2.h (MERGEPID):  Define.

Thanks - I've checked it in.  (Wonder if there should be a common
config/tm-sol2.h?)

	Andrew
From ac131313@cygnus.com Tue Feb 29 05:54:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: "Peter.Schauer" <Peter.Schauer@regent.e-technik.tu-muenchen.de>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: Patches to allow GDB to use NEW_PROC_API on Solaris x86
Date: Tue, 29 Feb 2000 05:54:00 -0000
Message-id: <38BBCF0F.B38E9DB3@cygnus.com>
References: <200002281744.SAA05324@reisser.regent.e-technik.tu-muenchen.de>
X-SW-Source: 2000-02/msg00077.html
Content-length: 1240

"Peter.Schauer" wrote:
> 
> These patches will allow GDB to use NEW_PROC_API on Solaris x86.
> 
> Currently GDB is not yet configured to use NEW_PROC_API, but it might be
> in the future (I am making progress on hardware watchpoint support for
> Solaris x86, which works only under the new API).
> 
> They clean up an old hack in sol-thread.c, which is no longer necessary
> with the new procfs.c code (thanks a lot Michael Snyder, I assume that you
> will have to approve these patches also).
> 
> The patches cause no testsuite regressions, with or without NEW_PROC_ABI
> defined.
> 
> 2000-02-28  Peter Schauer  <pes@regent.e-technik.tu-muenchen.de>
> 
>         Make NEW_PROC_ABI interface functional on Solaris x86.
>         * sol-thread.c (ps_lgetLDT):  Rewrite to use new procfs_find_LDT_entry
>         function from procfs.c, mostly copied from lin-thread.c.
>         * inferior.h, procfs.c (procfs_get_pid_fd):  Removed, no longer needed.
> 

I've applied the attatched.  One observation - I like how the comment:

> !   /* NOTE: only used on Solaris, therefore OK to refer to procfs.c */
> !   extern struct ssd *procfs_find_LDT_entry (int);
> !   struct ssd *ret;

was coppied to lin-thread.c and then back again :-)

	Andrew
From ac131313@cygnus.com Tue Feb 29 06:02:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Maurizio Palesi <mpalesi@sun131.iit.unict.it>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: instruction trace file
Date: Tue, 29 Feb 2000 06:02:00 -0000
Message-id: <38BBD13C.6D6F51AE@cygnus.com>
References: <38BA76BC.62659DF8@sun131.iit.unict.it>
X-SW-Source: 2000-02/msg00078.html
Content-length: 550

Maurizio Palesi wrote:
> 
> Hi all,
>     Is there a method to generate an instruction by instruction
> execution trace file of a program? From an executable file i wish to
> obtain an instruction trace file with following information:
> - address where instruction was fetched
> - instruction name
> - if memory access: address and data
> Thanks to all,
>     Maurizio

Using one of GDB's simulators then probably yes.
Using gdb and a normal target probably not (it would manage the insn
address/name but not the memory accesses).

	enjoy,
		Andrew
From ac131313@cygnus.com Tue Feb 29 06:03:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: [Fwd: Updated tools]
Date: Tue, 29 Feb 2000 06:03:00 -0000
Message-id: <38BBD180.5EBCF466@cygnus.com>
X-SW-Source: 2000-02/msg00079.html
Content-length: 380

Now what this means for GDB I'm not sure.

	Andrew


To : binutils at sourceware dot cygnus dot com
Subject : Updated tools
From : Ian Lance Taylor <ian at zembu dot com>
Date : 27 Feb 2000 11:58:18 -0500

I updated the snapshots of autoconf, automake, libtool and gettext in
ftp://sourceware.cygnus.com/pub/binutils .  I rebuilt the generated
files using the new sources.

Ian