* Re: RFA: gdbarch_free
2000-04-01 0:00 RFA: gdbarch_free Jim Blandy
@ 2000-02-28 17:03 ` Andrew Cagney
2000-04-01 0:00 ` Jim Blandy
0 siblings, 1 reply; 4+ messages in thread
From: Andrew Cagney @ 2000-02-28 17:03 UTC (permalink / raw)
To: Jim Blandy; +Cc: gdb-patches
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: RFA: gdbarch_free
2000-04-01 0:00 ` Jim Blandy
@ 2000-03-01 8:52 ` Jim Blandy
0 siblings, 0 replies; 4+ messages in thread
From: Jim Blandy @ 2000-03-01 8:52 UTC (permalink / raw)
To: Andrew Cagney; +Cc: Jim Blandy, gdb-patches
> > 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.
Whenever one provides an allocation function, one should always
provide a corresponding free function --- it gives you more freedom in
the way you allocate the object.
Why I'm freeing a gdbarch structure isn't really anyone's business but
my own. The contract of the init function is simply that it returns
null or a valid gdbarch; who knows how I might go about creating that
gdbarch. I might build it myself, for all you know.
The real story:
gdbarch_update calls the initialization function and checks the return
value. If it's zero, it says "gdbarch_update: Target rejected
architecture". I have an architecture with several variants, and I
want to return zero when the variant (info.bfd_arch_info->mach)
doesn't match anything I recognize.
This situation could arise if someone adds support for a new variant
of my architecture, but hasn't updated GDB yet.
I could check for this earlier, before calling gdbarch_alloc, but I'd
like to avoid having two `if' structures that need to stay in sync.
From assign@gnu.org Wed Mar 01 09:03:00 2000
From: assignments <assign@gnu.org>
To: gdb-patches@sourceware.cygnus.com
Subject: GDB assigns/disclaims
Date: Wed, 01 Mar 2000 09:03:00 -0000
Message-id: <200003011702.MAA11121@delysid.gnu.org>
X-SW-Source: 2000-03/msg00007.html
Content-length: 985
The following disclaimers and/or assignments concerning GDB
have recently been added to the file copyright.list here at the
Free Software Foundation. If you have any questions or corrections,
please send them to my general work address, 3diff@gnu.org.
Thanks!
Brian Youmans
Assignments Clerk
GDB Yutaka Niibe Japan 1967 2000-01-08
Assigns past and future changes (sh-stub.c).
gniibe@chroot.org
ANY BINUTILS GCC GDB GLIBC GUILE Mitsubishi Research Institute, Inc. 2000-01-11
Disclaims changes to free software and "operating system components" by
Yutaka Niibe, in the past and for the next 30 years.
GDB Pierre Muller France 1965 2000-02-11
Assigns past and future changes (pascal support).
muller@ics.u-strasbg.fr
GDB Daniel Berlin US ? 2000-02-11
Assigns past and future changes (beos-hat.[ch], beossolib.c).
dan@cgsoftware.com
From donnte@microsoft.com Wed Mar 01 09:28:00 2000
From: Donn Terry <donnte@microsoft.com>
To: 'Philippe De Muyter' <phdm@macqel.be>, ac131313@cygnus.com
Cc: ezannoni@cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: RE: HAVE_POLL is not enough
Date: Wed, 01 Mar 2000 09:28:00 -0000
Message-id: <BB61526CDE70D2119D0F00805FBECA2F12A39A06@RED-MSG-55>
X-SW-Source: 2000-03/msg00008.html
Content-length: 3838
I'm in a similar boat, except that:
Only poll() works some places (/proc).
Only select() works other places (pty/tty).
(This is a consequence of a "step in the right
direction", but the 2d step hasn't happened yet.)
Writing the /proc stuff to dynamically switch would
be a pain (at best).
The test really belongs in configure, but lacking
that it probably belongs in the manually configured
header files. (Something along the lines of
(for the default):
#ifdef HAVE_POLL
#define USE_POLL_ON_PROC
#define USE_POLL_ON_TTY
#else
#undef USE_POLL_ON_PROC
#undef USE_POLL_ON_TTY
#endif
For special cases (using mine as an example):
#undef USE_POLL_ON_TTY
#undef USE_POLL_ON_PROC // Just for error prevention
#define USE_POLL_ON_PROC
Donn Terry
Speaking only for myself, of course.
> -----Original Message-----
> From: Philippe De Muyter [ mailto:phdm@macqel.be ]
> Sent: None
> To: ac131313@cygnus.com
> Cc: ezannoni@cygnus.com; gdb-patches@sourceware.cygnus.com
> Subject: Re: HAVE_POLL is not enough
>
>
> First of all, sorry for the long delay for answers, but I am
> really busy
> (and more) with my day-hours work.
>
> > Elena Zannoni wrote:
> > >
> > > Philippe De Muyter writes:
> > > > With the gdb cvs tree of 2000-02-19, on
> m68k-motorola-sys, configure
> > > > correctly detect that we have `poll', but gdb
> incorrectly assumes that
> > > > `poll' can be used to wait for `stdin'. On
> m68k-motorola-sysv, tty's
> > > > are not stream-based and not `poll'able. Should the
> configure test
> > > > be enhanced ? I don't think so if we need to run a
> target program to check
> > > > that, because it would fail if we cross-compile gdb,
> but if it can be
> > > > determined by other ways, like the presence of some
> constants in some
> > > > header files then I would agree. We could also always
> compile in the `poll'
> > > > version if HAVE_POLL, but switch to the the fall-back
> method at run time if
> > > > poll fails with POLLNVAL.
> > > >
> > >
> > > Right now the decision on whether to run gdb with or
> without the event
> > > loop is determined by the user as start up, and it is not detected
> > > neither by configure or at run time. The easiest thing to
> do for now
>
> I did not ask explicitly to start gdb with or without the
> event-loop, and it
> tried automatically to use the event-loop. I don't know why
> but that seems
> to invalidate Elena's statement that `it is determined by the
> user as start up'.
>
> > > is probably tell the user what happened and switch to
> > > non-event-loop mode. Maybe some configury work could be done to
> > > determine whether the tty's can be pollable, I am not
> familiar with
> > > your system enough to know whether this is anything
> feasible. Sorry I
> > > cannot be of more help here.
> > > How about the 'target async' part, would that work?
> >
> > As far as I know, this problem is still present.
> >
> > Following on from Elena's comment. Is there any known work
> around or
> > other hack available?
> >
> > If we get really desparate there is always the option of putting:
> >
> > HOST_POLL_BROKEN
> >
> > in
> >
> > config/m68k/xm-m68kv4.h
> >
> > :-( (And yes, I'm about to get really desperate).
> >
> > Philippe, if GDB is forced to use select, does it work?
>
> If we never use poll, and always use select if it is
> available, I think
> we'll then have the inverse problem : platforms where some
> channels are
> `poll'-able, but not `select'-able.
>
> So, my idea is : at gdb startup, first poll the needed fd's
> one by one with
> a null or small timeout, and if one is not `poll'-able, then
> switch to `select'.
> I know that on m68k-motorola-sysv, `stdin' is `select'-able,
> so this scheme
> would work.
>
> Sorry, no time for a patch at the moment.
>
> >
> > Andrew
> >
>
From ezannoni@cygnus.com Wed Mar 01 11:37:00 2000
From: Elena Zannoni <ezannoni@cygnus.com>
To: "Philippe De Muyter" <phdm@macqel.be>
Cc: ac131313@cygnus.com (Andrew Cagney), ezannoni@cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: HAVE_POLL is not enough
Date: Wed, 01 Mar 2000 11:37:00 -0000
Message-id: <14525.29055.263209.524839@kwikemart.cygnus.com>
References: <38BCBC3F.56354ECB@cygnus.com> <200003011430.PAA03609@mail.macqel.be>
X-SW-Source: 2000-03/msg00009.html
Content-length: 3047
Philippe De Muyter writes:
> First of all, sorry for the long delay for answers, but I am really busy
> (and more) with my day-hours work.
>
> > Elena Zannoni wrote:
> > >
> > > Philippe De Muyter writes:
> > > > With the gdb cvs tree of 2000-02-19, on m68k-motorola-sys, configure
> > > > correctly detect that we have `poll', but gdb incorrectly assumes that
> > > > `poll' can be used to wait for `stdin'. On m68k-motorola-sysv, tty's
> > > > are not stream-based and not `poll'able. Should the configure test
> > > > be enhanced ? I don't think so if we need to run a target program to check
> > > > that, because it would fail if we cross-compile gdb, but if it can be
> > > > determined by other ways, like the presence of some constants in some
> > > > header files then I would agree. We could also always compile in the `poll'
> > > > version if HAVE_POLL, but switch to the the fall-back method at run time if
> > > > poll fails with POLLNVAL.
> > > >
> > >
> > > Right now the decision on whether to run gdb with or without the event
> > > loop is determined by the user as start up, and it is not detected
> > > neither by configure or at run time. The easiest thing to do for now
>
> I did not ask explicitly to start gdb with or without the event-loop, and it
> tried automatically to use the event-loop. I don't know why but that seems
> to invalidate Elena's statement that `it is determined by the user as start up'.
>
Sorry, that was unclear, there is a --noasync switch you can start up
gdb with and that will not use the event loop, but the old command
loop. (assuming it hasn't suffered from bitrot).
Elena
> > > is probably tell the user what happened and switch to
> > > non-event-loop mode. Maybe some configury work could be done to
> > > determine whether the tty's can be pollable, I am not familiar with
> > > your system enough to know whether this is anything feasible. Sorry I
> > > cannot be of more help here.
> > > How about the 'target async' part, would that work?
> >
> > As far as I know, this problem is still present.
> >
> > Following on from Elena's comment. Is there any known work around or
> > other hack available?
> >
> > If we get really desparate there is always the option of putting:
> >
> > HOST_POLL_BROKEN
> >
> > in
> >
> > config/m68k/xm-m68kv4.h
> >
> > :-( (And yes, I'm about to get really desperate).
> >
> > Philippe, if GDB is forced to use select, does it work?
>
> If we never use poll, and always use select if it is available, I think
> we'll then have the inverse problem : platforms where some channels are
> `poll'-able, but not `select'-able.
>
> So, my idea is : at gdb startup, first poll the needed fd's one by one with
> a null or small timeout, and if one is not `poll'-able, then switch to `select'.
> I know that on m68k-motorola-sysv, `stdin' is `select'-able, so this scheme
> would work.
>
> Sorry, no time for a patch at the moment.
>
> >
> > Andrew
> >
>
From ezannoni@cygnus.com Wed Mar 01 12:19:00 2000
From: Elena Zannoni <ezannoni@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: PATCH committed: mi-cmd-disas.c
Date: Wed, 01 Mar 2000 12:19:00 -0000
Message-id: <14525.31581.437389.79600@kwikemart.cygnus.com>
X-SW-Source: 2000-03/msg00010.html
Content-length: 2303
FYI, I just committed this bit.
Elena
Index: ChangeLog-mi
===================================================================
RCS file: /cvs/src/src/gdb/mi/ChangeLog-mi,v
retrieving revision 1.3
diff -c -r1.3 ChangeLog-mi
*** ChangeLog-mi 2000/02/23 06:19:22 1.3
--- ChangeLog-mi 2000/03/01 20:17:12
***************
*** 1,3 ****
--- 1,9 ----
+ 2000-03-01 Elena Zannoni <ezannoni@kwikemart.cygnus.com>
+
+ * mi-cmd-disas.c (mi_cmd_disassemble): Use
+ ui_out_field_core_addr() instead of print_address_numeric(), to
+ maintain consistency throughout MI.
+
Wed Feb 23 17:09:39 2000 Andrew Cagney <cagney@b1.cygnus.com>
* mi-cmd-break.c, mi-cmd-disas.c, mi-cmd-stack.c, mi-cmd-var.c,
Index: mi-cmd-disas.c
===================================================================
RCS file: /cvs/src/src/gdb/mi/mi-cmd-disas.c,v
retrieving revision 1.3
diff -c -r1.3 mi-cmd-disas.c
*** mi-cmd-disas.c 2000/02/23 06:19:22 1.3
--- mi-cmd-disas.c 2000/03/01 20:17:12
***************
*** 418,425 ****
num_displayed++;
}
ui_out_list_begin (uiout, NULL);
! print_address_numeric (pc, 1, stb->stream);
! ui_out_field_stream (uiout, "address", stb);
if (!build_address_symbolic (pc, 0, &name, &offset, &filename, &line, &unmapped))
{
--- 418,424 ----
num_displayed++;
}
ui_out_list_begin (uiout, NULL);
! ui_out_field_core_addr (uiout, "address", pc);
if (!build_address_symbolic (pc, 0, &name, &offset, &filename, &line, &unmapped))
{
***************
*** 467,474 ****
num_displayed++;
}
ui_out_list_begin (uiout, NULL);
! print_address_numeric (pc, 1, stb->stream);
! ui_out_field_stream (uiout, "address", stb);
if (!build_address_symbolic (pc, 0, &name, &offset, &filename, &line, &unmapped))
{
--- 466,472 ----
num_displayed++;
}
ui_out_list_begin (uiout, NULL);
! ui_out_field_core_addr (uiout, "address", pc);
if (!build_address_symbolic (pc, 0, &name, &offset, &filename, &line, &unmapped))
{
From ac131313@cygnus.com Wed Mar 01 14:16:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Discussion <gdb@sourceware.cygnus.com>, GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: [MAINT] Daniel Berlin is C++ language maintainer
Date: Wed, 01 Mar 2000 14:16:00 -0000
Message-id: <38BD967B.CD2AF9F8@cygnus.com>
X-SW-Source: 2000-03/msg00011.html
Content-length: 336
Hello,
I'm very pleased to announce that Daniel Berlin has agreed to take on
the responsibility of C++ language support within GDB. As many are
probably aware, Dan's been contributing a flurry of patches that fix
numerous C++ problems for some time.
Nice day for it!
Andrew
C++ language support Daniel Berlin dan@cgsoftware.com
From kettenis@wins.uva.nl Wed Mar 01 15:33:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: jimb@cygnus.com
Cc: gdb-patches@sourceware.cygnus.com
Subject: [PATCH RFA] Linux/i386 signal trampoline code
Date: Wed, 01 Mar 2000 15:33:00 -0000
Message-id: <200003012333.e21NXDw01833@delius.kettenis.local>
X-SW-Source: 2000-03/msg00012.html
Content-length: 10858
Can I check this in?
[Jim, I've sent you this patch before, but I'd really like to get this
checked in, to get my hands free to do some generic i386 work (which
would also touch i386-tdep.c). There is one tiny difference: I moved
LINUX_SIGCONTEXT_{PC,SP}_OFFSET from config/i386/tm-linux.h to
i386-tdep.c. There is no point in having it in the header file since
it is only used by the code in i386-tdep.c]
It fixes one test in the test-suite that otherwise fails on Linux
2.2.15 with glibc 2.1.3. I've discussed things with Ulrich Drepper,
and the library internels on which this patch depends are considered
stable.
Mark
2000-03-02 Mark Kettenis <kettenis@gnu.org>
Fix support for Linux/i386 signal trampolines. The old approach
didn't work for Linux 2.2 and beyond, and didn't work with recent
versions of the GNU C library.
* i386-tdep.c (LINUX_RT_SIGTRAMP_INSN0, LINUX_RT_SIGTRAMP_OFFSET0,
LINUX_RT_SIGTRAMP_INSN1, LINUX_RT_SIGTRAMP_OFFSET1): New defines.
(linux_rt_sigtramp_code): New variable.
(LINUX_RT_SIGTRAMP_LEN): New define.
(i386_linux_rt_sigtramp_start): New function. Detect start of
signal trampolines for RT signals.
(i386_linux_sigtramp): Add support for RT signals.
(i386_linux_sigcontext_addr): New function.
(LINUX_SIGCONTEXT_PC_OFFSET, LINUX_SIGCONTEXT_SP_OFFSET): New
defines. Moved here from config/i386/tm-linux.h.
(i386_linux_sigtramp_saved_pc, i386_linux_sigtramp_saved_sp):
Reimplement in terms of i386_linux_sigcontext_addr.
* config/i386/tm-linux.h (LINUX_SIGCONTEXT_SIZE): Removed.
(LINUX_SIGCONTEXT_PC_OFFSET, LINUX_SIGCONTEXT_SP_OFFSET):
Moved to i386-tdep.c.
(IN_SIGTRAMP): Recognize the names of the signal tranmpolines used
by recent versions of the GNU C library.
Index: i386-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/i386-tdep.c,v
retrieving revision 1.4
diff -u -p -r1.4 i386-tdep.c
--- i386-tdep.c 2000/02/29 13:28:24 1.4
+++ i386-tdep.c 2000/03/01 23:23:46
@@ -781,11 +781,19 @@ i386v4_sigtramp_saved_pc (frame)
#ifdef I386_LINUX_SIGTRAMP
-/* When the i386 Linux kernel calls a signal handler, the return
- address points to a bit of code on the stack. This function
- returns whether the PC appears to be within this bit of code.
+/* Linux has two flavors of signals. Normal signal handlers, and
+ "realtime" (RT) signals. The RT signals can provide additional
+ information to the signal handler if the SA_SIGINFO flag is set
+ when establishing a signal handler using `sigaction'. It is not
+ unlikely that future versions of Linux will support SA_SIGINFO for
+ normal signals too. */
+
+/* When the i386 Linux kernel calls a signal handler and the
+ SA_RESTORER flag isn't set, the return address points to a bit of
+ code on the stack. This function returns whether the PC appears to
+ be within this bit of code.
- The instruction sequence is
+ The instruction sequence for normal signals is
pop %eax
mov $0x77,%eax
int $0x80
@@ -799,8 +807,16 @@ i386v4_sigtramp_saved_pc (frame)
order to identify a signal trampoline, but there doesn't seem to be
any other way. The IN_SIGTRAMP macro in tm-linux.h arranges to
only call us if no function name could be identified, which should
- be the case since the code is on the stack. */
+ be the case since the code is on the stack.
+ Detection of signal trampolines for handlers that set the
+ SA_RESTORER flag is in general not possible. Unfortunately this is
+ what the GNU C Library has been doing for quite some time now.
+ However, as of version 2.1.2, the GNU C Library uses signal
+ trampolines (named __restore and __restore_rt) that are identical
+ to the ones used by the kernel. Therefore, these trampolines are
+ supported too. */
+
#define LINUX_SIGTRAMP_INSN0 (0x58) /* pop %eax */
#define LINUX_SIGTRAMP_OFFSET0 (0)
#define LINUX_SIGTRAMP_INSN1 (0xb8) /* mov $NNNN,%eax */
@@ -864,51 +880,151 @@ i386_linux_sigtramp_start (pc)
return pc;
}
+/* This function does the same for RT signals. Here the instruction
+ sequence is
+ mov $0xad,%eax
+ int $0x80
+ or 0xb8 0xad 0x00 0x00 0x00 0xcd 0x80.
+
+ The effect is to call the system call rt_sigreturn. */
+
+#define LINUX_RT_SIGTRAMP_INSN0 (0xb8) /* mov $NNNN,%eax */
+#define LINUX_RT_SIGTRAMP_OFFSET0 (0)
+#define LINUX_RT_SIGTRAMP_INSN1 (0xcd) /* int */
+#define LINUX_RT_SIGTRAMP_OFFSET1 (5)
+
+static const unsigned char linux_rt_sigtramp_code[] =
+{
+ LINUX_RT_SIGTRAMP_INSN0, 0xad, 0x00, 0x00, 0x00, /* mov $0xad,%eax */
+ LINUX_RT_SIGTRAMP_INSN1, 0x80 /* int $0x80 */
+};
+
+#define LINUX_RT_SIGTRAMP_LEN (sizeof linux_rt_sigtramp_code)
+
+/* If PC is in a RT sigtramp routine, return the address of the start
+ of the routine. Otherwise, return 0. */
+
+static CORE_ADDR
+i386_linux_rt_sigtramp_start (pc)
+ CORE_ADDR pc;
+{
+ unsigned char buf[LINUX_RT_SIGTRAMP_LEN];
+
+ /* We only recognize a signal trampoline if PC is at the start of
+ one of the two instructions. We optimize for finding the PC at
+ the start, as will be the case when the trampoline is not the
+ first frame on the stack. We assume that in the case where the
+ PC is not at the start of the instruction sequence, there will be
+ a few trailing readable bytes on the stack. */
+
+ if (read_memory_nobpt (pc, (char *) buf, LINUX_RT_SIGTRAMP_LEN) != 0)
+ return 0;
+
+ if (buf[0] != LINUX_RT_SIGTRAMP_INSN0)
+ {
+ if (buf[0] != LINUX_RT_SIGTRAMP_INSN1)
+ return 0;
+
+ pc -= LINUX_RT_SIGTRAMP_OFFSET1;
+
+ if (read_memory_nobpt (pc, (char *) buf, LINUX_RT_SIGTRAMP_LEN) != 0)
+ return 0;
+ }
+
+ if (memcmp (buf, linux_rt_sigtramp_code, LINUX_RT_SIGTRAMP_LEN) != 0)
+ return 0;
+
+ return pc;
+}
+
/* Return whether PC is in a Linux sigtramp routine. */
int
i386_linux_sigtramp (pc)
CORE_ADDR pc;
{
- return i386_linux_sigtramp_start (pc) != 0;
+ return (i386_linux_sigtramp_start (pc) != 0
+ || i386_linux_rt_sigtramp_start (pc) != 0);
}
-/* Assuming FRAME is for a Linux sigtramp routine, return the saved
- program counter. The Linux kernel will set up a sigcontext
- structure immediately before the sigtramp routine on the stack. */
+/* Assuming FRAME is for a Linux sigtramp routine, return the address
+ of the associated sigcontext structure. */
CORE_ADDR
-i386_linux_sigtramp_saved_pc (frame)
+i386_linux_sigcontext_addr (frame)
struct frame_info *frame;
{
CORE_ADDR pc;
pc = i386_linux_sigtramp_start (frame->pc);
- if (pc == 0)
- error ("i386_linux_sigtramp_saved_pc called when no sigtramp");
- return read_memory_integer ((pc
- - LINUX_SIGCONTEXT_SIZE
- + LINUX_SIGCONTEXT_PC_OFFSET),
- 4);
+ if (pc)
+ {
+ CORE_ADDR sp;
+
+ if (frame->next)
+ /* If this isn't the top frame, it must be the frame for the
+ signal handler itself. The sigcontext structure lives on
+ the stack, right after the signum argument. */
+ return frame->next->frame + 12;
+
+ /* This is the top frame. We'll have to find the address of the
+ sigcontext structure by looking at the stack pointer. Keep
+ in mind that the first instruction of the sigtramp code is
+ "pop %eax". If the PC is at this instruction, adjust the
+ returned value accordingly. */
+ sp = read_register (SP_REGNUM);
+ if (pc == frame->pc)
+ return sp + 4;
+ return sp;
+ }
+
+ pc = i386_linux_rt_sigtramp_start (frame->pc);
+ if (pc)
+ {
+ if (frame->next)
+ /* If this isn't the top frame, it must be the frame for the
+ signal handler itself. The sigcontext structure is part of
+ the user context. A pointer to the user context is passed
+ as the third argument to the signal handler. */
+ return read_memory_integer (frame->next->frame + 16, 4) + 20;
+
+ /* This is the top frame. Again, use the stack pointer to find
+ the address of the sigcontext structure. */
+ return read_memory_integer (read_register (SP_REGNUM) + 8, 4) + 20;
+ }
+
+ error ("Couldn't recognize signal trampoline.");
+ return 0;
}
+/* Offset to saved PC in sigcontext, from <asm/sigcontext.h>. */
+#define LINUX_SIGCONTEXT_PC_OFFSET (56)
+
/* Assuming FRAME is for a Linux sigtramp routine, return the saved
- stack pointer. The Linux kernel will set up a sigcontext structure
- immediately before the sigtramp routine on the stack. */
+ program counter. */
CORE_ADDR
-i386_linux_sigtramp_saved_sp (frame)
+i386_linux_sigtramp_saved_pc (frame)
struct frame_info *frame;
{
- CORE_ADDR pc;
+ CORE_ADDR addr;
+ addr = i386_linux_sigcontext_addr (frame);
+ return read_memory_integer (addr + LINUX_SIGCONTEXT_PC_OFFSET, 4);
+}
- pc = i386_linux_sigtramp_start (frame->pc);
- if (pc == 0)
- error ("i386_linux_sigtramp_saved_sp called when no sigtramp");
- return read_memory_integer ((pc
- - LINUX_SIGCONTEXT_SIZE
- + LINUX_SIGCONTEXT_SP_OFFSET),
- 4);
+/* Offset to saved SP in sigcontext, from <asm/sigcontext.h>. */
+#define LINUX_SIGCONTEXT_SP_OFFSET (28)
+
+/* Assuming FRAME is for a Linux sigtramp routine, return the saved
+ stack pointer. */
+
+CORE_ADDR
+i386_linux_sigtramp_saved_sp (frame)
+ struct frame_info *frame;
+{
+ CORE_ADDR addr;
+ addr = i386_linux_sigcontext_addr (frame);
+ return read_memory_integer (addr + LINUX_SIGCONTEXT_SP_OFFSET, 4);
}
#endif /* I386_LINUX_SIGTRAMP */
Index: config/i386/tm-linux.h
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/tm-linux.h,v
retrieving revision 1.1.1.8
diff -u -p -r1.1.1.8 tm-linux.h
--- config/i386/tm-linux.h 1999/12/07 03:56:10 1.1.1.8
+++ config/i386/tm-linux.h 2000/03/01 23:23:46
@@ -30,15 +30,6 @@
#include "i386/tm-i386.h"
#include "tm-linux.h"
-/* Size of sigcontext, from <asm/sigcontext.h>. */
-#define LINUX_SIGCONTEXT_SIZE (88)
-
-/* Offset to saved PC in sigcontext, from <asm/sigcontext.h>. */
-#define LINUX_SIGCONTEXT_PC_OFFSET (56)
-
-/* Offset to saved SP in sigcontext, from <asm/sigcontext.h>. */
-#define LINUX_SIGCONTEXT_SP_OFFSET (28)
-
#define LOW_RETURN_REGNUM 0 /* holds low four bytes of result */
#define HIGH_RETURN_REGNUM 2 /* holds high four bytes of result */
@@ -108,7 +99,9 @@ extern int i387_store_floating (PTR ad
order to support backtracing through calls to signal handlers. */
#define I386_LINUX_SIGTRAMP
-#define IN_SIGTRAMP(pc, name) ((name) == NULL && i386_linux_sigtramp (pc))
+#define IN_SIGTRAMP(pc, name) \
+ ((name) ? (STREQ ("__restore", name) || STREQ ("__restore_rt", name)) \
+ : i386_linux_sigtramp (pc))
extern int i386_linux_sigtramp PARAMS ((CORE_ADDR));
From kettenis@wins.uva.nl Wed Mar 01 15:40:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: ac131313@cygnus.com
Cc: gdb@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: [MAINT] x86 maintainers .....
Date: Wed, 01 Mar 2000 15:40:00 -0000
Message-id: <200003012340.e21Ne6o00157@delius.kettenis.local>
References: <38BCA2B9.3BDE66AD@cygnus.com>
X-SW-Source: 2000-03/msg00013.html
Content-length: 406
Date: Wed, 01 Mar 2000 15:55:21 +1100
From: Andrew Cagney <ac131313@cygnus.com>
Hello,
I'd like to put forward the following:
x86 target Mark Kettenis kettenis@gnu.org
GNU/Linux/x86 native & host
Jim Blandy jimb@cygnus.com
Mark Kettenis kettenis@gnu.org
No problems with those. I'll start working on those once you've added
them to the MAINTAINERS file :-).
Mark
From ac131313@cygnus.com Wed Mar 01 21:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Discussion <gdb@sourceware.cygnus.com>
Cc: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: [MAINT] Peter Schauer and Michael Snyder for ``Blanket Write'' maintainers
Date: Wed, 01 Mar 2000 21:00:00 -0000
Message-id: <38BDF545.34DB6172@cygnus.com>
X-SW-Source: 2000-03/msg00014.html
Content-length: 454
Hello,
I'd like to put forward that both:
Michael Snyder msnyder@cygnus.com
Peter Schauer
Peter.Schauer@regent.e-technik.tu-muenchen.de
be added to the ``Blanket Write Privs'' maintainers list.
Michael Snyder has been hacking continuously on GDB since at least '96
and stands as Red Hat's most experienced GDB developer. In Peter
Shauer, case he has been working on improving GDB for much longer (the
early '90).
Andrew
From kingdon@redhat.com Wed Mar 01 21:52:00 2000
From: Jim Kingdon <kingdon@redhat.com>
To: ac131313@cygnus.com
Cc: gdb-patches@sourceware.cygnus.com, blizzard@mozilla.org
Subject: Re: dlclose()
Date: Wed, 01 Mar 2000 21:52:00 -0000
Message-id: <200003020552.AAA07061@devserv.devel.redhat.com>
References: <200002161953.OAA07411@devserv.devel.redhat.com> <38BD058E.51313D7D@cygnus.com>
X-SW-Source: 2000-03/msg00015.html
Content-length: 5974
> One fix, and some extra random noise:
OK, I've changed assert() to internal_error() and reworded the
comment. PTR is also gone.
I don't know how the WITHDRAWN thing is supposed to work, but this
patch supercedes the two that I already posted under the subject line
"dlclose()".
> JimB's got the final say.
Well, any reactions, JimB? We don't have any other solib.c
maintainers yet. I also haven't heard from Mark Kettenis recently on
this issue - I know he was talking about an solib.c rewrite (not
something I disagree with, really), but that was in the context of a
rather different patch (even if it addressed the same problem).
2000-02-20 Jim Kingdon <kingdon@redhat.com>
* solib.c (find_solib): New argument recheck.
* solib.c (solib_add): Pass it as 1, and add logic to delete
shared libraries which aren't still in the inferior.
(struct so_list): New field found_me, for solib_add.
* solib.c (other find_solib callers): Pass recheck as 0.
Index: solib.c
===================================================================
RCS file: /cvs/src/src/gdb/solib.c,v
retrieving revision 1.1.1.10
diff -u -r1.1.1.10 solib.c
--- solib.c 1999/11/17 02:30:28 1.1.1.10
+++ solib.c 2000/03/02 05:19:21
@@ -143,6 +143,11 @@
char so_name[MAX_PATH_SIZE]; /* shared object lib name (FIXME) */
char symbols_loaded; /* flag: symbols read in yet? */
char from_tty; /* flag: print msgs? */
+
+ /* Flag for use within solib_add: have we seen this library actually
+ still mapped in the inferior this pass? */
+ char found_me;
+
struct objfile *objfile; /* objfile for loaded lib */
struct section_table *sections;
struct section_table *sections_end;
@@ -181,8 +186,7 @@
static int symbol_add_stub PARAMS ((PTR));
-static struct so_list *
- find_solib PARAMS ((struct so_list *));
+static struct so_list *find_solib (struct so_list *, int);
static struct link_map *
first_link_map_member PARAMS ((void));
@@ -975,8 +979,10 @@
*/
static struct so_list *
-find_solib (so_list_ptr)
- struct so_list *so_list_ptr; /* Last lm or NULL for first one */
+find_solib (struct so_list *so_list_ptr,
+ /* Nonzero if we should read all the entries from the inferior,
+ not just the ones at the end of the list. */
+ int recheck)
{
struct so_list *so_list_next = NULL;
struct link_map *lm = NULL;
@@ -985,7 +991,9 @@
if (so_list_ptr == NULL)
{
/* We are setting up for a new scan through the loaded images. */
- if ((so_list_next = so_list_head) == NULL)
+ so_list_next = so_list_head;
+ if (so_list_next == NULL
+ || recheck)
{
/* We have not already read in the dynamic linking structures
from the inferior, lookup the address of the base structure. */
@@ -1002,7 +1010,8 @@
{
/* We have been called before, and are in the process of walking
the shared library list. Advance to the next shared object. */
- if ((lm = LM_NEXT (so_list_ptr)) == NULL)
+ lm = LM_NEXT (so_list_ptr);
+ if (recheck || lm == NULL)
{
/* We have hit the end of the list, so check to see if any were
added, but be quiet if we can't read from the target any more. */
@@ -1020,7 +1029,7 @@
}
so_list_next = so_list_ptr->next;
}
- if ((so_list_next == NULL) && (lm != NULL))
+ if ((so_list_next == NULL || recheck) && (lm != NULL))
{
/* Get next link map structure from inferior image and build a local
abbreviated load_map structure */
@@ -1188,7 +1197,7 @@
/* Count how many new section_table entries there are. */
so = NULL;
count = 0;
- while ((so = find_solib (so)) != NULL)
+ while ((so = find_solib (so, 0)) != NULL)
{
if (so->so_name[0] && !match_main (so->so_name))
{
@@ -1201,7 +1210,7 @@
/* Add these section table entries to the target's table. */
old = target_resize_to_sections (target, count);
- while ((so = find_solib (so)) != NULL)
+ while ((so = find_solib (so, 0)) != NULL)
{
if (so->so_name[0])
{
@@ -1215,9 +1224,13 @@
}
}
+ for (so = so_list_head; so != NULL; so = so->next)
+ so->found_me = 0;
+
/* Now add the symbol files. */
- while ((so = find_solib (so)) != NULL)
+ while ((so = find_solib (so, 1)) != NULL)
{
+ so->found_me = 1;
if (so->so_name[0] && re_exec (so->so_name) &&
!match_main (so->so_name))
{
@@ -1240,6 +1253,44 @@
}
}
+ {
+ struct so_list *prev;
+ prev = NULL;
+ for (so = so_list_head; so != NULL; so = so->next)
+ {
+ if (!so->found_me)
+ {
+ /* If there were an analogue to
+ disable_breakpoints_in_shlibs but just for this one
+ struct so_list, we'd call it. */
+
+ if (so->sections != NULL)
+ free (so->sections);
+
+ free_objfile (so->objfile);
+
+ /* Punt the issue of the section tables that we put in the
+ target vector. The excuse is that they are basically
+ used for coredumps rather than running programs, and
+ with coredumps we don't unload shared libraries. */
+
+ if (so->abfd == NULL)
+ internal_error ("no bfd in solib_add");
+ if (!bfd_close (so->abfd))
+ warning ("cannot close \"%s\": %s",
+ so->so_name, bfd_errmsg (bfd_get_error ()));
+
+ if (prev == NULL)
+ so_list_head = so->next;
+ else
+ prev->next = so->next;
+
+ free (so);
+ }
+ prev = so;
+ }
+ }
+
/* Getting new symbols may change our opinion about what is
frameless. */
if (so_last)
@@ -1289,7 +1340,7 @@
addr_fmt = "016l";
#endif
- while ((so = find_solib (so)) != NULL)
+ while ((so = find_solib (so, 0)) != NULL)
{
if (so->so_name[0])
{
@@ -1347,7 +1398,7 @@
{
register struct so_list *so = 0; /* link map state variable */
- while ((so = find_solib (so)) != NULL)
+ while ((so = find_solib (so, 0)) != NULL)
{
if (so->so_name[0])
{
From kingdon@redhat.com Wed Mar 01 22:00:00 2000
From: Jim Kingdon <kingdon@redhat.com>
To: gdb-patches@sourceware.cygnus.com
Subject: Re: [MAINT] Minor admin tweeks
Date: Wed, 01 Mar 2000 22:00:00 -0000
Message-id: <b900153hd.fsf@rtl.cygnus.com>
References: <38BC6514.DC70948@cygnus.com>
X-SW-Source: 2000-03/msg00016.html
Content-length: 361
* MAINTAINERS: Document people with paperwork pending.
Sorry, I'm a bit confused by this one. Did you mean "+" rather than
"*" for the people you added the symbol to ("*" means that they don't
have an account, according to the key)?
Philippe De Muyter seems to have the right listing in copyright.html
(1996-06-12). As does JT Conklin (1998-12-21).
From ac131313@cygnus.com Wed Mar 01 22:22:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Jim Kingdon <kingdon@redhat.com>
Cc: gdb-patches@sourceware.cygnus.com, blizzard@mozilla.org
Subject: Re: dlclose()
Date: Wed, 01 Mar 2000 22:22:00 -0000
Message-id: <38BE083D.9F600CA6@cygnus.com>
References: <200002161953.OAA07411@devserv.devel.redhat.com> <38BD058E.51313D7D@cygnus.com> <200003020552.AAA07061@devserv.devel.redhat.com>
X-SW-Source: 2000-03/msg00017.html
Content-length: 864
Jim Kingdon wrote:
>
> > One fix, and some extra random noise:
>
> OK, I've changed assert() to internal_error() and reworded the
> comment. PTR is also gone.
>
> I don't know how the WITHDRAWN thing is supposed to work, but this
> patch supercedes the two that I already posted under the subject line
> "dlclose()".
>
> > JimB's got the final say.
> I don't know how the WITHDRAWN thing is supposed to work, but this
> patch supercedes the two that I already posted under the subject line
> "dlclose()".
Sorry, I've probably confused everyone.
It's when someone realizes that their patch is completely stuffed (you
can find examples of me doing this on the binutils mailing list :-) and
want to either drop it or rewrite it. Posting a note saying hey I'm
withdrawing this patch gives the discussion closure.
You're doing none of this,
sorry,
Andrew
From ac131313@cygnus.com Wed Mar 01 22:29:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Jim Kingdon <kingdon@redhat.com>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: [MAINT] Minor admin tweeks
Date: Wed, 01 Mar 2000 22:29:00 -0000
Message-id: <38BE0A0E.ED3A565B@cygnus.com>
References: <38BC6514.DC70948@cygnus.com> <b900153hd.fsf@rtl.cygnus.com>
X-SW-Source: 2000-03/msg00018.html
Content-length: 769
Jim Kingdon wrote:
>
> * MAINTAINERS: Document people with paperwork pending.
>
> Sorry, I'm a bit confused by this one. Did you mean "+" rather than
> "*" for the people you added the symbol to ("*" means that they don't
> have an account, according to the key)?
>
> Philippe De Muyter seems to have the right listing in copyright.html
> (1996-06-12). As does JT Conklin (1998-12-21).
The ChangeLog entry (poorly worded) in combination with the file changes
have thrown a few people.
As you note, the footnotes are:
* Indicates folks we need to get
Kerberos/ssh accounts ready so they
can write in the source tree
+ Indicates folks that have been caught up in a paper trail.
I was refering to the ``account request form'' paperwork.
Andrew
From kevinb@cygnus.com Wed Mar 01 23:47:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH RFA] store_floating(), extract_floating() fixes
Date: Wed, 01 Mar 2000 23:47:00 -0000
Message-id: <1000302074643.ZM19182@ocotillo.lan>
References: <1000229000345.ZM15006@ocotillo.lan> <38BCE46B.CD7889B5@cygnus.com> <ac131313@cygnus.com>
X-SW-Source: 2000-03/msg00019.html
Content-length: 218
On Mar 1, 8:35pm, Andrew Cagney wrote:
> > * findvar.c (extract_floating, store_floating): Use target
> > floating point type sizes rather host sizes to determine
[...]
> Approved.
Committed.
Kevin
From kettenis@wins.uva.nl Thu Mar 02 07:52:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: gdb-patches@sourceware.cygnus.com
Subject: [PATCH] AIX/i386 config tweaks
Date: Thu, 02 Mar 2000 07:52:00 -0000
Message-id: <200003021552.e22FqXZ09797@delius.kettenis.local>
X-SW-Source: 2000-03/msg00020.html
Content-length: 2936
FYI, I have checked in the following.
This is untested, but AIX/i386 was broken anyway, and in theory this
should fix it. The problem is that
i386-tdep.c:i386_extract_return_value() accessed the FP0_REGNUM in
GDB's register array, but since the reorganization of tm-i386.h last
fall, the register array wasn't large enough anymore.
It also clears the way for some changes I'm planning to make to
i386-tdep.c:i386_extract_return_value().
Mark
2000-03-02 Mark Kettenis <kettenis@gnu.org>
* config/i386/tm-i386aix.h (NUM_FPREGS, NUM_REGS, REGISTER_BYTES):
Override definitions to include the normal FPU registers.
(REGISTER_CONVERTIBLE, REGISTER_CONVERT_TO_VIRTUAL,
REGISTER_CONVERT_TO_RAW): Removed. The default definitions are
fine for AIX/i386.
(i387_to_double, double_to_i387): Remove prototypes.
Index: config/i386/tm-i386aix.h
===================================================================
RCS file: /cvs/src/src/gdb/config/i386/tm-i386aix.h,v
retrieving revision 1.1.1.2
diff -u -p -r1.1.1.2 tm-i386aix.h
--- config/i386/tm-i386aix.h 1999/07/07 20:13:03 1.1.1.2
+++ config/i386/tm-i386aix.h 2000/03/02 15:37:29
@@ -29,40 +29,27 @@
#ifndef I386
#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
-
-/* Nonzero if register N requires conversion
- from raw format to virtual format. */
-
-#undef REGISTER_CONVERTIBLE
-#define REGISTER_CONVERTIBLE(N) \
- ((N < FP0_REGNUM) ? 0 : 1)
-
-/* Convert data from raw format for register REGNUM in buffer FROM
- to virtual format with type TYPE in buffer TO. */
-#undef REGISTER_CONVERT_TO_VIRTUAL
-#define REGISTER_CONVERT_TO_VIRTUAL(REGNUM,TYPE,FROM,TO) \
-{ \
- double val; \
- i387_to_double ((FROM), (char *)&val); \
- store_floating ((TO), TYPE_LENGTH (TYPE), val); \
-}
-extern void
-i387_to_double PARAMS ((char *, char *));
+/* 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
+ only the normal FPU registers are included in GDB's register array. */
+
+#undef NUM_FPREGS
+#define NUM_FPREGS (8)
-/* Convert data from virtual format with type TYPE in buffer FROM
- to raw format for register REGNUM in buffer TO. */
+#undef NUM_REGS
+#define NUM_REGS (NUM_GREGS + NUM_FPREGS)
-#undef REGISTER_CONVERT_TO_RAW
-#define REGISTER_CONVERT_TO_RAW(TYPE,REGNUM,FROM,TO) \
-{ \
- double val = extract_floating ((FROM), TYPE_LENGTH (TYPE)); \
- double_to_i387((char *)&val, (TO)); \
-}
-extern void
-double_to_i387 PARAMS ((char *, char *));
+#undef REGISTER_BYTES
+#define REGISTER_BYTES (SIZEOF_GREGS + SIZEOF_FPU_REGS)
#endif /* TM_I386AIX_H */
From scottb@netwinder.org Thu Mar 02 11:35:00 2000
From: Scott Bambrough <scottb@netwinder.org>
To: GDB Patches Mail List <gdb-patches@sourceware.cygnus.com>
Subject: Patches and the patch database...
Date: Thu, 02 Mar 2000 11:35:00 -0000
Message-id: <38BEC141.9D299C3B@netwinder.org>
X-SW-Source: 2000-03/msg00021.html
Content-length: 427
Hi guys,
I decided to exercise the patch database. I sent a whole whack of patches to
get rid of the deprecated macros TARGET_BYTE_ORDER and
TARGET_BYTE_ORDER_SELECTABLE. It might be useful to have an architecture field
on the web form. That would make it easier to search for ARM patches for
instance.
Scott
--
Scott Bambrough - Software Engineer
REBEL.COM http://www.rebel.com
NetWinder http://www.netwinder.org
From ezannoni@cygnus.com Thu Mar 02 15:18:00 2000
From: Elena Zannoni <ezannoni@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: PATCH corefiles reading on alpha-linux
Date: Thu, 02 Mar 2000 15:18:00 -0000
Message-id: <14526.63171.337788.889969@kwikemart.cygnus.com>
X-SW-Source: 2000-03/msg00022.html
Content-length: 1733
gdb/config/alpha/alpha-linux.mh lists core-regset.o as one of
the NATDEPFILES.
This causes _initialize_core_regset() to be called, and this in turn
calls add_core_fns with bfd_target_elf_flavour.
Later on, _initialize_core_alpha() adds another core function
structure with the same flavour. When a core file is loaded, this
causes a warning to be printed, because both function sets match the
expected bfd flavour.
I am going to check this in. OK?
Elena
Index: alpha-linux.mh
===================================================================
RCS file: /cvs/src/src/gdb/config/alpha/alpha-linux.mh,v
retrieving revision 1.1.1.3
diff -c -r1.1.1.3 alpha-linux.mh
*** alpha-linux.mh 1999/12/22 21:45:12 1.1.1.3
--- alpha-linux.mh 2000/03/02 23:15:59
***************
*** 2,8 ****
XDEPFILES= ser-tcp.o
XM_FILE= xm-alphalinux.h
NAT_FILE= nm-linux.h
! NATDEPFILES= infptrace.o inftarg.o corelow.o core-regset.o alpha-nat.o \
fork-child.o solib.o linux-thread.o lin-thread.o
LOADLIBES = -ldl -rdynamic
--- 2,8 ----
XDEPFILES= ser-tcp.o
XM_FILE= xm-alphalinux.h
NAT_FILE= nm-linux.h
! NATDEPFILES= infptrace.o inftarg.o corelow.o alpha-nat.o \
fork-child.o solib.o linux-thread.o lin-thread.o
LOADLIBES = -ldl -rdynamic
Index: ChangeLog
===================================================================
RCS file: /cvs/src/src/gdb/ChangeLog,v
retrieving revision 1.95
diff -c -r1.95 ChangeLog
*** ChangeLog 2000/03/02 15:44:27 1.95
--- ChangeLog 2000/03/02 23:17:32
***************
*** 1,3 ****
--- 1,8 ----
+ 2000-03-02 Elena Zannoni <ezannoni@kwikemart.cygnus.com>
+
+ * config/alpha/alpha-linux.mh: Remove core-regset.o fron the
+ NATDEPFILES list.
+
^ permalink raw reply [flat|nested] 4+ messages in thread
* RFA: gdbarch_free
@ 2000-04-01 0:00 Jim Blandy
2000-02-28 17:03 ` Andrew Cagney
0 siblings, 1 reply; 4+ messages in thread
From: Jim Blandy @ 2000-04-01 0:00 UTC (permalink / raw)
To: gdb-patches
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.
Index: gdb/gdbarch.sh
===================================================================
RCS file: /cvs/src/src/gdb/gdbarch.sh,v
retrieving revision 1.4
diff -c -r1.4 gdbarch.sh
*** gdbarch.sh 2000/02/23 02:42:40 1.4
--- gdbarch.sh 2000/02/28 23:01:13
***************
*** 512,517 ****
--- 512,521 ----
extern struct gdbarch *gdbarch_alloc (const struct gdbarch_info *info, struct gdbarch_tdep *tdep);
+ /* Helper function. Free a partially-constructed \`\`struct gdbarch''. */
+ extern void gdbarch_free (struct gdbarch *);
+
+
/* Helper function. Force an update of the current architecture. Used
by legacy targets that have added their own target specific
architecture manipulation commands.
***************
*** 958,963 ****
--- 962,984 ----
/* gdbarch_alloc() */
return gdbarch;
+ }
+ EOF
+
+ # Free a gdbarch struct.
+ echo ""
+ echo ""
+ cat <<EOF
+ /* Free a gdbarch struct. This should never happen in normal
+ operation --- once you've created a gdbarch, you keep it around.
+ However, if an architecture's init function encounters an error
+ building the structure, it may need to clean up a partially
+ constructed gdbarch. */
+ void
+ gdbarch_free (struct gdbarch *arch)
+ {
+ /* At the moment, this is trivial. */
+ free (arch);
}
EOF
Index: gdb/gdbarch.c
===================================================================
RCS file: /cvs/src/src/gdb/gdbarch.c,v
retrieving revision 1.3
diff -c -r1.3 gdbarch.c
*** gdbarch.c 2000/02/22 19:17:27 1.3
--- gdbarch.c 2000/02/28 23:01:16
***************
*** 357,362 ****
--- 357,375 ----
}
+ /* Free a gdbarch struct. This should never happen in normal
+ operation --- once you've created a gdbarch, you keep it around.
+ However, if an architecture's init function encounters an error
+ building the structure, it may need to clean up a partially
+ constructed gdbarch. */
+ void
+ gdbarch_free (struct gdbarch *arch)
+ {
+ /* At the moment, this is trivial. */
+ free (arch);
+ }
+
+
/* Ensure that all values in a GDBARCH are reasonable. */
static void
Index: gdb/gdbarch.h
===================================================================
RCS file: /cvs/src/src/gdb/gdbarch.h,v
retrieving revision 1.3
diff -c -r1.3 gdbarch.h
*** gdbarch.h 2000/02/23 02:42:40 1.3
--- gdbarch.h 2000/02/28 23:01:18
***************
*** 909,914 ****
--- 909,918 ----
extern struct gdbarch *gdbarch_alloc (const struct gdbarch_info *info, struct gdbarch_tdep *tdep);
+ /* Helper function. Free a partially-constructed ``struct gdbarch''. */
+ extern void gdbarch_free (struct gdbarch *);
+
+
/* Helper function. Force an update of the current architecture. Used
by legacy targets that have added their own target specific
architecture manipulation commands.
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: list which remote protocol commands are required
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <5md7opufwl.fsf@jtc.redbacknetworks.com>
X-SW-Source: 2000-q1/msg00843.html
Content-length: 9902
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.
--jtc
2000-03-20 J.T. Conklin <jtc@redback.com>
* gdb.texinfo: Clarify which remote debug protocol commands are
required and which are optional.
Index: gdb.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v
retrieving revision 1.4
diff -c -r1.4 gdb.texinfo
*** gdb.texinfo 2000/03/20 22:51:36 1.4
--- gdb.texinfo 2000/03/21 03:59:16
***************
*** 8835,8840 ****
--- 8835,8844 ----
protocol. A newer @value{GDBN} can tell if a packet is supported based
on that response.
+ A stub is required to support the @samp{g}, @samp{G}, @samp{m}, @samp{M},
+ @samp{c}, and @samp{s} @var{command}s. All other @var{command}s are
+ optional.
+
Below is a complete list of all currently defined @var{command}s and
their corresponding response @var{data}:
***************
*** 8843,8849 ****
@tab Request
@tab Description
! @item extended ops @emph{(optional)}
@tab @code{!}
@tab
Use the extended remote protocol. Sticky---only needs to be set once.
--- 8847,8853 ----
@tab Request
@tab Description
! @item extended ops
@tab @code{!}
@tab
Use the extended remote protocol. Sticky---only needs to be set once.
***************
*** 8869,8875 ****
@tab @code{a}
@tab Reserved for future use
! @item set program arguments @strong{(reserved)} @emph{(optional)}
@tab @code{A}@var{arglen}@code{,}@var{argnum}@code{,}@var{arg}@code{,...}
@tab
Initialized @samp{argv[]} array passed into program. @var{arglen}
--- 8873,8879 ----
@tab @code{a}
@tab Reserved for future use
! @item set program arguments @strong{(reserved)}
@tab @code{A}@var{arglen}@code{,}@var{argnum}@code{,}@var{arg}@code{,...}
@tab
Initialized @samp{argv[]} array passed into program. @var{arglen}
***************
*** 8909,8915 ****
@tab reply
@tab see below
! @item continue with signal @emph{(optional)}
@tab @code{C}@var{sig}@code{;}@var{addr}
@tab
Continue with signal @var{sig} (hex signal number). If
--- 8913,8919 ----
@tab reply
@tab see below
! @item continue with signal
@tab @code{C}@var{sig}@code{;}@var{addr}
@tab
Continue with signal @var{sig} (hex signal number). If
***************
*** 8923,8929 ****
@tab
toggle debug flag.
! @item detach @emph{(optional)}
@tab @code{D}
@tab
Detach @value{GDBN} from the remote system. Sent to the remote target before
--- 8927,8933 ----
@tab
toggle debug flag.
! @item detach
@tab @code{D}
@tab
Detach @value{GDBN} from the remote system. Sent to the remote target before
***************
*** 8980,8986 ****
@tab @code{h}
@tab Reserved for future use
! @item set thread @emph{(optional)}
@tab @code{H}@var{c}@var{t...}
@tab
Set thread for subsequent operations (@samp{m}, @samp{M}, @samp{g},
--- 8984,8990 ----
@tab @code{h}
@tab Reserved for future use
! @item set thread
@tab @code{H}@var{c}@var{t...}
@tab
Set thread for subsequent operations (@samp{m}, @samp{M}, @samp{g},
***************
*** 9009,9022 ****
@c selected, sets the registers of the register block of
@c that thread; otherwise sets current registers.
! @item cycle step @strong{(draft)} @emph{(optional)}
@tab @code{i}@var{addr}@code{,}@var{nnn}
@tab
Step the remote target by a single clock cycle. If @code{,}@var{nnn} is
present, cycle step @var{nnn} cycles. If @var{addr} is present, cycle
step starting at that address.
! @item signal then cycle step @strong{(reserved)} @emph{(optional)}
@tab @code{I}
@tab
See @samp{i} and @samp{S} for likely syntax and semantics.
--- 9013,9026 ----
@c selected, sets the registers of the register block of
@c that thread; otherwise sets current registers.
! @item cycle step @strong{(draft)}
@tab @code{i}@var{addr}@code{,}@var{nnn}
@tab
Step the remote target by a single clock cycle. If @code{,}@var{nnn} is
present, cycle step @var{nnn} cycles. If @var{addr} is present, cycle
step starting at that address.
! @item signal then cycle step @strong{(reserved)}
@tab @code{I}
@tab
See @samp{i} and @samp{S} for likely syntax and semantics.
***************
*** 9029,9035 ****
@tab @code{J}
@tab Reserved for future use
! @item kill request @emph{(optional)}
@tab @code{k}
@tab
FIXME: @emph{There is no description of how operate when a specific
--- 9033,9039 ----
@tab @code{J}
@tab Reserved for future use
! @item kill request
@tab @code{k}
@tab
FIXME: @emph{There is no description of how operate when a specific
***************
*** 9099,9105 ****
@tab return @var{r....}
@tab The hex encoded value of the register in target byte order.
! @item write reg @emph{(optional)}
@tab @code{P}@var{n...}@code{=}@var{r...}
@tab
Write register @var{n...} with value @var{r...}, which contains two hex
--- 9103,9109 ----
@tab return @var{r....}
@tab The hex encoded value of the register in target byte order.
! @item write reg
@tab @code{P}@var{n...}@code{=}@var{r...}
@tab
Write register @var{n...} with value @var{r...}, which contains two hex
***************
*** 9111,9117 ****
@tab reply @code{E}@var{NN}
@tab for an error
! @item general query @emph{(optional)}
@tab @code{q}@var{query}
@tab
Request info about @var{query}. In general @value{GDBN} @var{query}'s
--- 9115,9121 ----
@tab reply @code{E}@var{NN}
@tab for an error
! @item general query
@tab @code{q}@var{query}
@tab
Request info about @var{query}. In general @value{GDBN} @var{query}'s
***************
*** 9129,9135 ****
@tab reply @samp{}
@tab Indicating an unrecognized @var{query}.
! @item general set @emph{(optional)}
@tab @code{Q}@var{var}@code{=}@var{val}
@tab
Set value of @var{var} to @var{val}. See @samp{q} for a discussing of
--- 9133,9139 ----
@tab reply @samp{}
@tab Indicating an unrecognized @var{query}.
! @item general set
@tab @code{Q}@var{var}@code{=}@var{val}
@tab
Set value of @var{var} to @var{val}. See @samp{q} for a discussing of
***************
*** 9140,9153 ****
@tab
Reset the entire system.
! @item remote restart @emph{(optional)}
@tab @code{R}@var{XX}
@tab
Restart the remote server. @var{XX} while needed has no clear
definition. FIXME: @emph{An example interaction explaining how this
packet is used in extended-remote mode is needed}.
! @item step @emph{(optional)}
@tab @code{s}@var{addr}
@tab
@var{addr} is address to resume. If @var{addr} is omitted, resume at
--- 9144,9157 ----
@tab
Reset the entire system.
! @item remote restart
@tab @code{R}@var{XX}
@tab
Restart the remote server. @var{XX} while needed has no clear
definition. FIXME: @emph{An example interaction explaining how this
packet is used in extended-remote mode is needed}.
! @item step
@tab @code{s}@var{addr}
@tab
@var{addr} is address to resume. If @var{addr} is omitted, resume at
***************
*** 9156,9162 ****
@tab reply
@tab see below
! @item step with signal @emph{(optional)}
@tab @code{S}@var{sig}@code{;}@var{addr}
@tab
Like @samp{C} but step not continue.
--- 9160,9166 ----
@tab reply
@tab see below
! @item step with signal
@tab @code{S}@var{sig}@code{;}@var{addr}
@tab
Like @samp{C} but step not continue.
***************
*** 9164,9177 ****
@tab reply
@tab see below
! @item search @emph{(optional)}
@tab @code{t}@var{addr}@code{:}@var{PP}@code{,}@var{MM}
@tab
Search backwards starting at address @var{addr} for a match with pattern
@var{PP} and mask @var{MM}. @var{PP} and @var{MM} are 4
bytes. @var{addr} must be at least 3 digits.
! @item thread alive @emph{(optional)}
@tab @code{T}@var{XX}
@tab Find out if the thread XX is alive.
@item
--- 9168,9181 ----
@tab reply
@tab see below
! @item search
@tab @code{t}@var{addr}@code{:}@var{PP}@code{,}@var{MM}
@tab
Search backwards starting at address @var{addr} for a match with pattern
@var{PP} and mask @var{MM}. @var{PP} and @var{MM} are 4
bytes. @var{addr} must be at least 3 digits.
! @item thread alive
@tab @code{T}@var{XX}
@tab Find out if the thread XX is alive.
@item
***************
*** 9209,9215 ****
@tab @code{x}
@tab Reserved for future use
! @item write mem (binary) @emph{(optional)}
@tab @code{X}@var{addr}@code{,}@var{length}@var{:}@var{XX...}
@tab
@var{addr} is address, @var{length} is number of bytes, @var{XX...} is
--- 9213,9219 ----
@tab @code{x}
@tab Reserved for future use
! @item write mem (binary)
@tab @code{X}@var{addr}@code{,}@var{length}@var{:}@var{XX...}
@tab
@var{addr} is address, @var{length} is number of bytes, @var{XX...} is
***************
*** 9230,9241 ****
@tab @code{Y}
@tab Reserved for future use
! @item remove break or watchpoint @strong{(draft)} @emph{(optional)}
@tab @code{z}@var{t}@code{,}@var{addr}@code{,}@var{length}
@tab
See @samp{Z}.
! @item insert break or watchpoint @strong{(draft)} @emph{(optional)}
@tab @code{Z}@var{t}@code{,}@var{addr}@code{,}@var{length}
@tab
@var{t} is type: @samp{0} - software breakpoint, @samp{1} - hardware
--- 9234,9245 ----
@tab @code{Y}
@tab Reserved for future use
! @item remove break or watchpoint @strong{(draft)}
@tab @code{z}@var{t}@code{,}@var{addr}@code{,}@var{length}
@tab
See @samp{Z}.
! @item insert break or watchpoint @strong{(draft)}
@tab @code{Z}@var{t}@code{,}@var{addr}@code{,}@var{length}
@tab
@var{t} is type: @samp{0} - software breakpoint, @samp{1} - hardware
--
J.T. Conklin
RedBack Networks
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Discussion <gdb@sourceware.cygnus.com>
Cc: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: [MAINT] x86 maintainers .....
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38BCA2B9.3BDE66AD@cygnus.com>
X-SW-Source: 2000-q1/msg00437.html
Content-length: 318
Hello,
I'd like to put forward the following:
x86 target Mark Kettenis kettenis@gnu.org
GNU/Linux/x86 native & host
Jim Blandy jimb@cygnus.com
Mark Kettenis kettenis@gnu.org
Solaris/x86 native & host
Nick Duffek nsd@cygnus.com
Peter Schauer Peter.Schauer@regent.e-technik.tu-muenchen.de
Andrew
From ac131313@cygnus.com Sat Apr 01 00:00: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: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38BB2D7D.4081A59B@cygnus.com>
References: <38ACA4D6.993AFF74@cygnus.com>
X-SW-Source: 2000-q1/msg00411.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 Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Philippe GIACINTI <Philippe.Giacinti@sxb.bsf.alcatel.fr>
Cc: gdb-patches@sourceware.cygnus.com, Michael Snyder <msnyder@cygnus.com>
Subject: Re: [PATCH] minor fixes in remote.c
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38D5CB49.6F9CF39@cygnus.com>
References: <14549.49859.878539.158465@gargle.gargle.HOWL>
X-SW-Source: 2000-q1/msg00801.html
Content-length: 1918
Philippe GIACINTI wrote:
>
> Hi,
>
> Here is a patch including minor fixes in file gdb/remote.c:
>
> * remote.c (record_currthread): must call `set_thread' to change
> general thread, in order to let stub know we have changed it.
> * remote.c (remote_read_bytes): when we need to read more memory
> than max buffer size, we have to reserve space for leading $ and
> trailing # + checksum (i.e.: 4 char)
>
> Best regards.
> --
> Philippe Giacinti - Alcatel Business Systems - PCD/SMB/SWPCC - CC S0645
> 1, route du Dr Albert Schweitzer - 67408 Illkirch Cedex - FRANCE
> Tel: +33 (0)3.90.67.62.10 - Fax: +33 (0)3.90.67.77.93
> mailto:Philippe.Giacinti@sxb.bsf.alcatel.fr
>
> ------------------------------------------------------------------------
> --- insight-20000314.old/gdb/remote.c Fri Feb 18 18:00:18 2000
> +++ insight-20000314/gdb/remote.c Fri Mar 17 09:00:54 2000
FYI,
> @@ -742,7 +742,7 @@
> record_currthread (currthread)
> int currthread;
> {
> - general_thread = currthread;
> + set_thread (currthread,1);
>
> /* If this is a new thread, add it to GDB's thread list.
> If we leave it up to WFI to do this, bad things will happen. */
This is more MichaelS's domain.
> @@ -3439,7 +3439,8 @@
> int todo;
> int i;
>
> - todo = min (len, max_buf_size / 2); /* num bytes that will fit */
> + todo = min (len, max_buf_size / 2 - 4); /* num bytes that will fit */
> + /* -4 for leading $ and trailing # + checksum (2 hex chars) */
>
> /* construct "m"<memaddr>","<len>" */
> /* sprintf (buf, "m%lx,%x", (unsigned long) memaddr, todo); */
> --- insight-20000314.old/gdb/ChangeLog Tue Mar 14 03:37:24 2000
> +++ insight-20000314/gdb/ChangeLog Fri Mar 17 13:29:21 2000
Can you expand on this one a little?
There were several nasty buffer overflow bugs but they should have been
fixed.
Andrew
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: Re: Heads up - Alpha ISO-C fixes
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38C072EC.56B02FA9@cygnus.com>
References: <38BF7D8C.BE18FAAF@cygnus.com>
X-SW-Source: 2000-q1/msg00492.html
Content-length: 3168
This one hurts. Things to do post 5.0 is think about ISO-C-fying
mmalloc :-)
Andrew
Sat Mar 4 13:02:09 2000 Andrew Cagney <cagney@b1.cygnus.com>
* utils.c (mcalloc), defs.h (mcalloc): Keep consistent with
"mmalloc.h" which means using PTRs.
(init_malloc, msavestring, mstrsave): Convert to PTR free ISO-C.
Index: gdb/defs.h
===================================================================
RCS file: /cvs/src/src/gdb/defs.h,v
retrieving revision 1.8
diff -p -r1.8 defs.h
*** defs.h 2000/03/04 01:15:32 1.8
--- defs.h 2000/03/04 02:18:00
*************** extern int myread (int, char *, int);
*** 341,347 ****
extern int query (char *, ...) ATTR_FORMAT (printf, 1, 2);
#if !defined (USE_MMALLOC)
! extern PTR mcalloc (void *, size_t, size_t);
extern PTR mmalloc (PTR, size_t);
extern PTR mrealloc (PTR, PTR, size_t);
extern void mfree (PTR, PTR);
--- 341,350 ----
extern int query (char *, ...) ATTR_FORMAT (printf, 1, 2);
#if !defined (USE_MMALLOC)
! /* NOTE: cagney/2000-03-04: The mmalloc functions need to use PTR
! rather than void* so that they are consistent with
! ../mmalloc/mmalloc.h. */
! extern PTR mcalloc (PTR, size_t, size_t);
extern PTR mmalloc (PTR, size_t);
extern PTR mrealloc (PTR, PTR, size_t);
extern void mfree (PTR, PTR);
Index: gdb/utils.c
===================================================================
RCS file: /cvs/src/src/gdb/utils.c,v
retrieving revision 1.3
diff -p -r1.3 utils.c
*** utils.c 2000/03/04 00:40:40 1.3
--- utils.c 2000/03/04 02:18:07
*************** request_quit (signo)
*** 919,926 ****
#if !defined (USE_MMALLOC)
! void *
! mcalloc (void *md, size_t number, size_t size)
{
return calloc (number, size);
}
--- 919,926 ----
#if !defined (USE_MMALLOC)
! PTR
! mcalloc (PTR md, size_t number, size_t size)
{
return calloc (number, size);
}
*************** mfree (md, ptr)
*** 958,965 ****
#if !defined (USE_MMALLOC) || defined (NO_MMCHECK)
void
! init_malloc (md)
! PTR md;
{
}
--- 958,964 ----
#if !defined (USE_MMALLOC) || defined (NO_MMCHECK)
void
! init_malloc (void *md)
{
}
*************** malloc_botch ()
*** 991,998 ****
#endif
void
! init_malloc (md)
! PTR md;
{
if (!mmcheckf (md, malloc_botch, MMCHECK_FORCE))
{
--- 990,996 ----
#endif
void
! init_malloc (void *md)
{
if (!mmcheckf (md, malloc_botch, MMCHECK_FORCE))
{
*************** savestring (ptr, size)
*** 1149,1158 ****
}
char *
! msavestring (md, ptr, size)
! PTR md;
! const char *ptr;
! int size;
{
register char *p = (char *) xmmalloc (md, size + 1);
memcpy (p, ptr, size);
--- 1147,1153 ----
}
char *
! msavestring (void *md, const char *ptr, int size)
{
register char *p = (char *) xmmalloc (md, size + 1);
memcpy (p, ptr, size);
*************** strsave (ptr)
*** 1171,1179 ****
}
char *
! mstrsave (md, ptr)
! PTR md;
! const char *ptr;
{
return (msavestring (md, ptr, strlen (ptr)));
}
--- 1166,1172 ----
}
char *
! mstrsave (void *md, const char *ptr)
{
return (msavestring (md, ptr, strlen (ptr)));
}
From kingdon@redhat.com Sat Apr 01 00:00:00 2000
From: Jim Kingdon <kingdon@redhat.com>
To: gdb-patches@sourceware.cygnus.com
Subject: Re: new GDB soon?
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <bpuu88cir.fsf@rtl.cygnus.com>
References: <200002071923.OAA30606@flib.gnu.ai.mit.edu> <389F25B8.18196557@cygnus.com> <200002072222.RAA32524@delysid.gnu.org>
X-SW-Source: 2000-q1/msg00093.html
Content-length: 207
> If someone sets me up with a copy of the Texinfo file(s), I would be
> happy to send some corrections or bug reports
http://sourceware.cygnus.com/cgi-bin/cvsweb.cgi/src/gdb/doc/gdb.texinfo?cvsroot=src
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>, "Insight (GDB GUI)" <insight@sourceware.cygnus.com>
Subject: GDB_FILE -> struct ui_file cleanup
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <389644AD.A93A9E7C@cygnus.com>
X-SW-Source: 2000-q1/msg00063.html
Content-length: 1928
Hmm,
I've just checked in a jumbo cleanup patch (and it is going to hurt)
that replaces GDB_FILE / ``struct gdb_file'' with a uniform ``struct
ui_file''.
I've attatched the relevant ChangeLog entries.
Andrew
ChangeLog:
Tue Feb 1 00:17:12 2000 Andrew Cagney <cagney@b1.cygnus.com>
* ui-file.c, ui-file.h: Rename gdb-file.h, gdb-file.c. Rename
``struct gdb_file'' to ``struct ui_file''. Delete typedef
GDB_FILE.
* Makefile.in: Update.
* ax-gdb.c, ax-general.c, ax.h, buildsym.c, c-lang.c, c-lang.h,
c-typeprint.c, c-valprint.c, ch-lang.c, ch-lang.h, ch-typeprint.c,
ch-valprint.c, command.c, command.h, convex-tdep.c, corefile.c,
cp-valprint.c, d10v-tdep.c, d30v-tdep.c, defs.h, expprint.c,
expression.h, f-lang.c, f-lang.h, f-typeprint.c, f-valprint.c,
frame.h, gdb-events.sh, gdb-file.c, gdb-file.h, gdbcmd.h,
gdbtypes.h, hppa-tdep.c, jv-lang.c, jv-lang.h, jv-typeprint.c,
jv-valprint.c, language.c, language.h, m2-lang.c, m2-lang.h,
m2-typeprint.c, m2-valprint.c, m3-nat.c, main.c, monitor.c,
printcmd.c, pyr-tdep.c, remote-mips.c, remote-sim.c, remote-udi.c,
remote.c, scm-lang.c, scm-lang.h, scm-valprint.c, ser-e7kpc.c,
ser-go32.c, ser-mac.c, ser-ocd.c, ser-unix.c, ser-unix.h,
serial.c, serial.h, stack.c, symfile.c, symmisc.c, tahoe-tdep.c,
target.c, target.h, top.c, top.h, typeprint.c, typeprint.h,
utils.c, v850ice.c, valprint.c, valprint.h, value.h,
config/pa/tm-hppa.h: Update.
ChangeLog-gdbtk:
Tue Feb 1 00:17:12 2000 Andrew Cagney <cagney@b1.cygnus.com>
* gdbtk-hooks.c, gdbtk-variable.c, gdbtk-wrapper.c,
gdbtk-wrapper.h, gdbtk.h: Update to reflect rename of gdb-file /
GDB_FILE to ui-file / ``struct ui_file''.
tui/ChangeLog:
Tue Feb 1 00:17:12 2000 Andrew Cagney <cagney@b1.cygnus.com>
* tui-file.c, tui-file.h, tuiDisassem.c, tuiIO.c, tuiIO.h,
tuiRegs.c: Update to reflect rename of gdb-file / GDB_FILE to
ui-file / ``struct ui_file''.
From scottb@netwinder.org Sat Apr 01 00:00:00 2000
From: "Scott Bambrough" <scottb@netwinder.org>
To: "Nick Clifton" <nickc@cygnus.com>
Cc: <fnasser@cygnus.com>, <gdb-patches@sourceware.cygnus.com>
Subject: Re: RFC: Patch to arm-tdep.c -- Register flavors
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <000d01bf782d$3193e260$LocalHost@fiji>
References: <200002152356.PAA16995@elmo.cygnus.com>
X-SW-Source: 2000-q1/msg00167.html
Content-length: 1139
> : I think the default register names should be set by the port. Most
Linux users
> : don't use the APCS/ATPCS register names. I don't find them intuitive at
all
> : myself.
>
> On the other hand, Cygnus customers have complained about the lack of
> A{T}PCS compliant register naming schemes and this patch is part of
> the work that was done to make them happy.
I guess if they like that sort of thing. I don't really know anyone who
uses them however. Unless you do?
> : Is the othernames command really necessary?
>
> Documenting a command is not hard. I suppoose the question the
> question is really "is this feature necessary ?". I would certainly
> think that the ability to invoke target-specific commands from within
> GDB would be useful (*) be they register renaming commands or
> something else.
In this case I guess it is really "is this feature really necessary?".
There are two ways of accomplishing the same thing; the othername command
seems redundant to me. Which is really the point I was trying to make. I
probably shouldn't try to write email when I'm in a rush to get out the door
to go home :(.
Scott
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: RFA: gdbarch_free
2000-02-28 17:03 ` Andrew Cagney
@ 2000-04-01 0:00 ` Jim Blandy
2000-03-01 8:52 ` Jim Blandy
0 siblings, 1 reply; 4+ messages in thread
From: Jim Blandy @ 2000-04-01 0:00 UTC (permalink / raw)
To: Andrew Cagney; +Cc: Jim Blandy, gdb-patches
> > 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.
Whenever one provides an allocation function, one should always
provide a corresponding free function --- it gives you more freedom in
the way you allocate the object.
Why I'm freeing a gdbarch structure isn't really anyone's business but
my own. The contract of the init function is simply that it returns
null or a valid gdbarch; who knows how I might go about creating that
gdbarch. I might build it myself, for all you know.
The real story:
gdbarch_update calls the initialization function and checks the return
value. If it's zero, it says "gdbarch_update: Target rejected
architecture". I have an architecture with several variants, and I
want to return zero when the variant (info.bfd_arch_info->mach)
doesn't match anything I recognize.
This situation could arise if someone adds support for a new variant
of my architecture, but hasn't updated GDB yet.
I could check for this earlier, before calling gdbarch_alloc, but I'd
like to avoid having two `if' structures that need to stay in sync.
From kevinb@cygnus.com Sat Apr 01 00:00:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: [PATCH] Shared library fixes for GNU/Linux/PPC port
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <1000225014927.ZM15386@ocotillo.lan>
X-SW-Source: 2000-q1/msg00362.html
Content-length: 10309
I've just committed several changes which fix two problems for the
GNU/Linux/PPC port.
1) Calling an inferior function which returns a structure didn't
work right. The structure address was not getting stored in r3 as
mandated by the SysV ABI. Also, the first argument to the
function was winding up in r4 instead of r3 in this case.
2) It was not possible to start gdb and then set a breakpoint on
a shared library function. Before I describe the exact nature
of the problem, I need to first describe some of the details
related to dynamic linking on this platform.
A call to a shared library function is accomplished via a bl
(branch-and-link) instruction whose branch target is an entry
in the procedure linkage table (PLT). The PLT (in the object)
file is uninitialized. To gdb, prior to running the program, the
entries in the PLT are all zeros.
Once the program starts running, the shared libraries are loaded
and the procedure linkage table is initialized, but the entries
in the table are not (necessarily) resolved. Once a function
is actually called, the code in the PLT is hit and the function
is resolved. In order to better illustrate this, I think an
example is in order; the following example is shmain from the gdb
testsuite. (Note that I ran this example *after* fixing the bug.)
We start the program shmain.
[kev@arroyo testsuite]$ ../gdb gdb.base/shmain
GNU gdb 20000204
[...]
We place two breakpoints, one on shr1 and the other on main.
(gdb) b shr1
Breakpoint 1 at 0x100409d4
(gdb) b main
Breakpoint 2 at 0x100006a0: file gdb.base/shmain.c, line 44.
Examine the instruction (and the immediatly following instruction)
upon which the breakpoint was placed. Note that the PLT entry
for shr1 contains zeros.
(gdb) x/2i 0x100409d4
0x100409d4 <shr1>: .long 0x0
0x100409d8 <shr1+4>: .long 0x0
Now run 'til main.
(gdb) r
Starting program: gdb.base/shmain
Breakpoint 1 at 0xffaf790: file gdb.base/shr1.c, line 19.
Breakpoint 2, main ()
at gdb.base/shmain.c:44
44 g = 1;
Examine the PLT again. Note that the loading of the shared
library has initialized the PLT to code which loads a constant
(which I think is an index into the GOT) into r11 and then
branchs a short distance to the code which actually does the
resolving.
(gdb) x/2i 0x100409d4
0x100409d4 <shr1>: li r11,4
0x100409d8 <shr1+4>: b 0x10040984 <sg+4>
(gdb) c
Continuing.
Breakpoint 1, shr1 (x=1)
at gdb.base/shr1.c:19
19 l = 1;
Now we've hit the breakpoint at shr1. (The breakpoint was
reset from the PLT entry to the actual shr1 function after the
shared library was loaded.) Note that the PLT entry has been
resolved to contain a branch that takes us directly to shr1.
(The real one, not the PLT entry.)
(gdb) x/2i 0x100409d4
0x100409d4 <shr1>: b 0xffaf76c <shr1>
0x100409d8 <shr1+4>: b 0x10040984 <sg+4>
The thing to note here is that the PLT entry for shr1 has been
changed twice.
There were two problems.
The first was that the prologue matching code would (incorrectly)
skip over the zeros because it was considering these to be one
of the following instructions:
st cr, NUM(r1)
or
st lr, NUM(r1)
It was a simple matter to fix the prologue scanner to only match
the above instructions. But this was a serious problem because
gdb would skip over *all of the zeros* in the PLT and would wind
up trying to set a breakpoint in some bit of unaccessible memory.
With that fix in place, however, there was still a problem. GDB
would place a breakpoint (a trap instruction) on the zero value
of the PLT entry for shr1. Later on, after the shared library
had been loaded and the PLT initialized, gdb would get a signal
indicating this fact and would (as it always does when it stops)
remove all the breakpoints.
This removal of the breakpoints was causing the former contents (a
zero word) to be written back to the now initialized PLT entry
thus destroying a portion of the initialization that had occurred
only a short time ago. When execution continued, the zero word
would be executed as an instruction an an illegal instruction trap
was generated instead. (0 is not a legal instruction.)
The fix for this was a bit more complicated. What I did was to
make a copy of memory_remove_breakpoint () from mem-break.c and
rename it to ppc_linux_memory_remove_breakpoint (). (I also made
a few minor changes which I'll describe shortly.) I made this new
function live in ppc-linux-tdep.c. In tm-linux.h, I then defined
MEMORY_REMOVE_BREAKPOINT to call this new function.
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.
For the time being, I'll leave this self-modifying-code-friendly
version in ppc-linux-tdep.c, but I think it ought to moved to
mem-break.c and be made the generic version.
Comments?
Below are the patches. I'm now seeing between 17 and 20 unexpected
failures on the GNU/Linux/PPC port. The exact number varies depending
upon whether gdb is compiled with optimization or not. (Some of the
tests in selftest.exp will fail when gdb is compiled with optimization
turned on.)
* ppc-linux-tdep.c (ppc_sysv_abi_push_arguments): Put address
of return structure in r3 if necessary.
(ppc_linux_memory_remove_breakpoints): New function.
* rs6000-tdep.c (skip_prologue): Make sure that the cases
for storing either cr or lr to the stack only handle those
cases. (I.e, don't let these cases match 0x00000000 which is
found found in the shared library trampoline prior to the
loading of the shared library.)
* config/powerpc/tm-linux.h (ppc_linux_memory_remove_breakpoint):
Declare.
(MEMORY_REMOVE_BREAKPOINT): Define.
Index: ppc-linux-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/ppc-linux-tdep.c,v
retrieving revision 1.2
diff -u -p -r1.2 ppc-linux-tdep.c
--- ppc-linux-tdep.c 2000/02/22 18:47:41 1.2
+++ ppc-linux-tdep.c 2000/02/24 22:46:53
@@ -522,6 +522,14 @@ ppc_sysv_abi_push_arguments (nargs, args
structoffset = argoffset + argstkspace;
freg = 1;
greg = 3;
+ /* Fill in r3 with the return structure, if any */
+ if (struct_return)
+ {
+ char val_buf[4];
+ store_address (val_buf, 4, struct_addr);
+ memcpy (®isters[REGISTER_BYTE (greg)], val_buf, 4);
+ greg++;
+ }
/* Now fill in the registers and stack... */
for (argno = 0; argno < nargs; argno++)
{
@@ -605,4 +613,30 @@ ppc_sysv_abi_push_arguments (nargs, args
target_store_registers (-1);
return sp;
+}
+
+/* This version of ppc_linux_memory_remove_breakpoints handles the
+ case of self modifying code */
+int
+ppc_linux_memory_remove_breakpoint (CORE_ADDR addr, char *contents_cache)
+{
+ unsigned char *bp;
+ int val;
+ int bplen;
+ char old_contents[BREAKPOINT_MAX];
+
+ /* Determine appropriate breakpoint contents and size for this address. */
+ bp = BREAKPOINT_FROM_PC (&addr, &bplen);
+ if (bp == NULL)
+ error ("Software breakpoints not implemented for this target.");
+
+ val = target_read_memory (addr, old_contents, bplen);
+
+ /* If our breakpoint is no longer at the address, this means that the
+ program modified the code on us, so it is wrong to put back the
+ old value */
+ if (val == 0 && memcmp (bp, old_contents, bplen) == 0)
+ val = target_write_memory (addr, contents_cache, bplen);
+
+ return val;
}
Index: rs6000-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/rs6000-tdep.c,v
retrieving revision 1.3
diff -u -p -r1.3 rs6000-tdep.c
--- rs6000-tdep.c 2000/02/22 01:20:32 1.3
+++ rs6000-tdep.c 2000/02/24 22:46:55
@@ -313,8 +313,8 @@ skip_prologue (pc, fdata)
char buf[4];
unsigned long op;
long offset = 0;
- int lr_reg = 0;
- int cr_reg = 0;
+ int lr_reg = -1;
+ int cr_reg = -1;
int reg;
int framep = 0;
int minimal_toc_loaded = 0;
@@ -391,7 +391,7 @@ skip_prologue (pc, fdata)
continue;
}
- else if ((op & 0xffff0000) == lr_reg)
+ else if (lr_reg != -1 && (op & 0xffff0000) == lr_reg)
{ /* st Rx,NUM(r1)
where Rx == lr */
fdata->lr_offset = SIGNED_SHORT (op) + offset;
@@ -400,7 +400,7 @@ skip_prologue (pc, fdata)
continue;
}
- else if ((op & 0xffff0000) == cr_reg)
+ else if (cr_reg != -1 && (op & 0xffff0000) == cr_reg)
{ /* st Rx,NUM(r1)
where Rx == cr */
fdata->cr_offset = SIGNED_SHORT (op) + offset;
Index: config/powerpc/tm-linux.h
===================================================================
RCS file: /cvs/src/src/gdb/config/powerpc/tm-linux.h,v
retrieving revision 1.2
diff -u -p -r1.2 tm-linux.h
--- tm-linux.h 2000/02/22 18:47:41 1.2
+++ tm-linux.h 2000/02/24 22:46:56
@@ -93,6 +93,13 @@ CORE_ADDR ppc_sysv_abi_push_arguments PA
#define PROLOGUE_FIRSTLINE_OVERLAP
#endif
+/* Needed to handled the self-modifying code situation due to the dynamic
+ linker. */
+int ppc_linux_memory_remove_breakpoint (CORE_ADDR addr, char *contents_cache);
+#undef MEMORY_REMOVE_BREAKPOINT
+#define MEMORY_REMOVE_BREAKPOINT(addr, contents_cache) \
+ ppc_linux_memory_remove_breakpoint(addr, contents_cache)
+
/* N_FUN symbols in shared libaries have 0 for their values and need
to be relocated. */
#define SOFUN_ADDRESS_MAYBE_MISSING
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2000-04-01 0:00 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-04-01 0:00 RFA: gdbarch_free Jim Blandy
2000-02-28 17:03 ` Andrew Cagney
2000-04-01 0:00 ` Jim Blandy
2000-03-01 8:52 ` Jim Blandy
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox