* Re: A patch for gnu-regex
[not found] ` <200003081758.SAA17064@landau.wins.uva.nl>
@ 2000-04-01 0:00 ` H . J . Lu
0 siblings, 0 replies; 3+ messages in thread
From: H . J . Lu @ 2000-04-01 0:00 UTC (permalink / raw)
To: Mark Kettenis; +Cc: jtc, shebs, gdb
On Wed, Mar 08, 2000 at 06:58:18PM +0100, Mark Kettenis wrote:
>
> I can add --enable-gdb-regex if it helps.
>
> If we decide to do so, could we then try to be consistent with other
> GNU packages that already let the user choose between the regex
> implementation distributed with that package, and the implementation
> in the C library, and us --with(out)-included-regex?
>
Here is a revised patch. It overrides:
http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00562.html
http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00566.html
H.J.
---
2000-03-08 H.J. Lu <hjl@gnu.org>
* gdb_regex.h: New. Include <regex.h> for glibc 2 and include
"gnu-regex.h" otherwise.
* irix5-nat.c: Include "gdb_regex.h" instead of "gnu-regex.h".
* monitor.c: Likewise.
* osfsolib.c: Likewise.
* solib.c: Likewise.
* source.c: Likewise.
* symtab.c: Likewise.
* Makefile.in (REGEX): Changed to @REGEX@.
(REGEX_CFLAGS): New.
(REGEX1): Removed.
(ADD_DEPS): Use $(REGEX) instead of $(REGEX1).
(INTERNAL_WARN_CFLAGS): Add $(REGEX_CFLAGS).
* configure.in (--with-included-regex): New switch.
(REGEX): New. Subsstitue @REGEX@ in Makefile.in.
(REGEX_CFLAGS): New. Subsstitue @REGEX_CFLAGS@ in Makefile.in.
* configure: Regenerated.
Index: configure.in
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/configure.in,v
retrieving revision 1.1.1.6
diff -u -p -r1.1.1.6 configure.in
--- configure.in 2000/03/07 18:42:10 1.1.1.6
+++ configure.in 2000/03/08 23:33:09
@@ -505,6 +505,34 @@ if test x$want_mmalloc = xtrue; then
MMALLOC='../mmalloc/libmmalloc.a'
fi
+AC_ARG_WITH(included-regex,
+[ --with-included-regex Use included regex],
+[case "${withval}" in
+ yes) want_included_regex=true ;;
+ no) want_included_regex=false;;
+ *) AC_MSG_ERROR(bad value ${withval} for GDB with-included-regex option) ;;
+esac],[want_included_regex=false])dnl
+
+REGEX="gnu-regex.o"
+REGEX_CFLAGS="-DUSE_INCLUDED_REGEX"
+if test $want_included_regex = false; then
+ AC_MSG_CHECKING(for GNU regex in glibc 2)
+ AC_CACHE_VAL(gdb_cv_have_glibc_2,
+[AC_TRY_COMPILE([#include <features.h>],
+[#if !defined __GLIBC__ || __GLIBC__ < 2
+#error It is not glibc 2.
+#endif
+],
+ [gdb_cv_have_glibc_2=yes],
+ [gdb_cv_have_glibc_2=no])])
+ AC_MSG_RESULT($gdb_cv_have_glibc_2)
+ if test $gdb_cv_have_glibc_2 = yes; then
+ REGEX=
+ REGEX_CFLAGS=
+ fi
+fi
+AC_SUBST(REGEX)
+AC_SUBST(REGEX_CFLAGS)
# In the Cygwin environment, we need some additional flags.
AC_CACHE_CHECK([for cygwin], gdb_cv_os_cygwin,
Index: irix5-nat.c
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/irix5-nat.c,v
retrieving revision 1.1.1.3
retrieving revision 1.3
diff -u -p -r1.1.1.3 -r1.3
--- irix5-nat.c 1999/11/19 23:38:46 1.1.1.3
+++ irix5-nat.c 2000/03/08 00:36:03 1.3
@@ -278,7 +278,7 @@ fetch_core_registers (core_reg_sect, cor
#include "objfiles.h"
#include "command.h"
#include "frame.h"
-#include "gnu-regex.h"
+#include "gdb_regex.h"
#include "inferior.h"
#include "language.h"
#include "gdbcmd.h"
Index: monitor.c
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/monitor.c,v
retrieving revision 1.1.1.5
retrieving revision 1.3
diff -u -p -r1.1.1.5 -r1.3
--- monitor.c 2000/03/07 18:42:14 1.1.1.5
+++ monitor.c 2000/03/08 00:36:03 1.3
@@ -50,7 +50,7 @@
#include "monitor.h"
#include "gdbcmd.h"
#include "inferior.h"
-#include "gnu-regex.h"
+#include "gdb_regex.h"
#include "dcache.h"
#include "srec.h"
Index: osfsolib.c
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/osfsolib.c,v
retrieving revision 1.1.1.3
retrieving revision 1.3
diff -u -p -r1.1.1.3 -r1.3
--- osfsolib.c 1999/11/19 23:38:50 1.1.1.3
+++ osfsolib.c 2000/03/08 00:36:03 1.3
@@ -36,7 +36,7 @@
#include "command.h"
#include "target.h"
#include "frame.h"
-#include "gnu-regex.h"
+#include "gdb_regex.h"
#include "inferior.h"
#include "language.h"
#include "gdbcmd.h"
Index: solib.c
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/solib.c,v
retrieving revision 1.1.1.4
retrieving revision 1.7
diff -u -p -r1.1.1.4 -r1.7
--- solib.c 2000/03/07 18:42:17 1.1.1.4
+++ solib.c 2000/03/08 18:36:11 1.7
@@ -49,7 +49,7 @@
#include "command.h"
#include "target.h"
#include "frame.h"
-#include "gnu-regex.h"
+#include "gdb_regex.h"
#include "inferior.h"
#include "environ.h"
#include "language.h"
Index: source.c
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/source.c,v
retrieving revision 1.1.1.3
retrieving revision 1.3
diff -u -p -r1.1.1.3 -r1.3
--- source.c 2000/02/04 20:21:58 1.1.1.3
+++ source.c 2000/03/08 00:36:03 1.3
@@ -33,7 +33,7 @@
#include "gdb_stat.h"
#include <fcntl.h>
#include "gdbcore.h"
-#include "gnu-regex.h"
+#include "gdb_regex.h"
#include "symfile.h"
#include "objfiles.h"
#include "annotate.h"
Index: symtab.c
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/symtab.c,v
retrieving revision 1.1.1.4
retrieving revision 1.3
diff -u -p -r1.1.1.4 -r1.3
--- symtab.c 2000/03/07 18:42:17 1.1.1.4
+++ symtab.c 2000/03/08 00:36:03 1.3
@@ -30,7 +30,7 @@
#include "objfiles.h"
#include "gdbcmd.h"
#include "call-cmds.h"
-#include "gnu-regex.h"
+#include "gdb_regex.h"
#include "expression.h"
#include "language.h"
#include "demangle.h"
Index: Makefile.in
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/Makefile.in,v
retrieving revision 1.1.1.9
diff -u -p -r1.1.1.9 Makefile.in
--- Makefile.in 2000/03/07 18:42:08 1.1.1.9
+++ Makefile.in 2000/03/08 23:48:52
@@ -114,6 +114,11 @@ LIBIBERTY = ../libiberty/libiberty.a
MMALLOC = @MMALLOC@
MMALLOC_CFLAGS = @MMALLOC_CFLAGS@
+# We are using our own version of REGEX now to be consistent across
+# machines.
+REGEX = @REGEX@
+REGEX_CFLAGS = @REGEX_CFLAGS@
+
# Where is the BFD library? Typically in ../bfd.
BFD_DIR = ../bfd
BFD = $(BFD_DIR)/libbfd.a
@@ -271,7 +276,8 @@ INTERNAL_WARN_CFLAGS = \
$(CFLAGS) $(GLOBAL_CFLAGS) $(PROFILE_CFLAGS) \
$(GDB_CFLAGS) $(OPCODES_CFLAGS) $(READLINE_CFLAGS) \
$(BFD_CFLAGS) $(MMALLOC_CFLAGS) $(INCLUDE_CFLAGS) \
- $(INTL_CFLAGS) $(TUI_CFLAGS) $(ENABLE_CFLAGS) $(GDB_WARN_CFLAGS)
+ $(INTL_CFLAGS) $(TUI_CFLAGS) $(ENABLE_CFLAGS) \
+ $(REGEX_CFLAGS) $(GDB_WARN_CFLAGS)
INTERNAL_CFLAGS = $(INTERNAL_WARN_CFLAGS) $(GDB_WERROR_CFLAGS)
# LDFLAGS is specifically reserved for setting from the command line
@@ -283,11 +289,6 @@ INTERNAL_CFLAGS = $(INTERNAL_WARN_CFLAGS
INTERNAL_LDFLAGS = $(CFLAGS) $(GLOBAL_CFLAGS) $(PROFILE_CFLAGS) $(LDFLAGS) $(CONFIG_LDFLAGS) @HLDFLAGS@
HLDENV = @HLDENV@
-# We are using our own version of REGEX now to be consistent across
-# machines.
-REGEX = gnu-regex.o
-REGEX1 = gnu-regex.o
-
# If your system is missing alloca(), or, more likely, it's there but
# it doesn't work, then refer to libiberty.
@@ -308,7 +309,7 @@ CDEPS = $(XM_CDEPS) $(TM_CDEPS) $(NAT_CD
$(OPCODES) $(MMALLOC) $(INTL_DEPS) $(LIBIBERTY) $(CONFIG_DEPS)
ADD_FILES = $(REGEX) $(XM_ADD_FILES) $(TM_ADD_FILES) $(NAT_ADD_FILES)
-ADD_DEPS = $(REGEX1) $(XM_ADD_FILES) $(TM_ADD_FILES) $(NAT_ADD_FILES)
+ADD_DEPS = $(REGEX) $(XM_ADD_FILES) $(TM_ADD_FILES) $(NAT_ADD_FILES)
VERSION = 20000204
DIST=gdb
--- /dev/null Tue May 5 13:32:27 1998
+++ gdb_regex.h Wed Mar 8 15:40:01 2000
@@ -0,0 +1,7 @@
+#ifndef _GDB_REGEX_H
+#if !defined USE_INCLUDED_REGEX && defined __GLIBC__ && __GLIBC__ >= 2
+#include <regex.h>
+#else
+#include "gnu-regex.h"
+#endif
+#endif /* _GDB_REGEX_H */
From eliz@delorie.com Sat Apr 01 00:00:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: kettenis@wins.uva.nl
Cc: gdb@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: `long double' support for ix86 targets
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003050805.DAA10149@indy.delorie.com>
References: <200003031531.e23FV8T00285@delius.kettenis.local>
X-SW-Source: 2000-q1/msg00542.html
Content-length: 885
> I intend to check in the following patch in a week or two, but since
> this change affects most of the ix86 targets, I'd like to give people
> the opportunity to object.
>
> Mark
>
>
> 2000-03-02 Mark Kettenis <kettenis@gnu.org>
>
> * config/i386/tm-i386.h (TARGET_LONG_DOUBLE_FORMAT): Define as
> &floatformat_i387_ext.
> (TARGET_LONG_DOUBLE_BITS): Define as 96.
> (REGISTER_VIRTUAL_TYPE): Change type for FPU registers to
> `builtin_type_long_double'.
> (REGISTER_CONVERT_TO_VIRTUAL): Simply copy over the data, and pad
> with zeroes.
> (REGISTER_CONVERT_TO_RAW): Simply copy over the significant data.
> (i387_to_double, double_to_i387): Remove prototypes.
These changes are okay for DJGPP.
Btw, shouldn't we also have identical definition for
HOST_LONG_DOUBLE_FORMAT for native debugging? Several functions ask
about the host and target format being identical.
From cgf@cygnus.com Sat Apr 01 00:00:00 2000
From: Chris Faylor <cgf@cygnus.com>
To: Brent Weech <weech@primenet.com>
Cc: gdb@sourceware.cygnus.com, cygwin@sourceware.cygnus.com
Subject: Re: GDB error 87 under Cygwin
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000227155217.A7612@cygnus.com>
References: <4.3.2.20000226214059.00b8f008@pop.primenet.com>
X-SW-Source: 2000-q1/msg00428.html
Content-length: 2097
On Sat, Feb 26, 2000 at 10:33:54PM -0700, Brent Weech wrote:
>Where in the world in the Errors.h file that enumerates the error codes
>coming from GDB? In particular, I am interested in error 87, as shown
>below:
That would be in the cygwin distribution. In later snapshots it's called
"winerror.h. If you grep for "ERROR_" you should be able to find the
correct file, whatever it is called.
>BLACKBOX> gdb h-hcube
>GNU gdb 4.18
>Copyright 1998 Free Software Foundation, Inc.
>GDB is free software, covered by the GNU General Public License, and you are
>welcome to change it and/or distribute copies of it under certain conditions.
>Type "show copying" to see the conditions.
>There is absolutely no warranty for GDB. Type "show warranty" for details.
>This GDB was configured as "i586-cygwin32"...(no debugging symbols found)...
>(gdb) r
>Starting program: //e/h-hcube.exe
>Error creating process //e/h-hcube.exe, (error 87)
Error 87 is "INVALID_PARAMETER". I'm not sure why this is happening,
unfortunately.
>I'm sure the answer to this question is somewhere on the Cygnus and/or
>GDB mailing archive, but for the life of me I can't figure out how to
>get the wonderfully worthless ht://Dig search engine to accept phrase
>or boolean searches with any accuracy. It has got to be one of the
>most frustrating search engine software packages I have ever used. For
>example, try the following: On the Cygwin Project archive, a search for
>"error 87" set to match all terms or a boolean search for "error and
>87" both give 5474 matches. On the same archive, a search for "error"
>gives (yes, I'm sure you can guess) the same 5474 matches! But on the
>same archive, a search for "error 193" set to match all terms only
>gives 21 hits.
Sorry. I don't know anything about the search engine. Possibly sending
email to sourcemaster@cygnus.com might help.
If you want to debug this, you could grab a precompiled version of gdb from
ftp://ftp.xraylith.wisc.edu/pub/khan/gnu-win32/cygwin/ports/
possibly, that would work better.
cgf
From cgf@cygnus.com Sat Apr 01 00:00:00 2000
From: Chris Faylor <cgf@cygnus.com>
To: David Williams <davidwilliams@ozemail.com.au>
Cc: Serge Nikulin <nikulin@actsw.amat.com>, gdb@sourceware.cygnus.com
Subject: Re: How to set RS232 speed in gdb in WinNT?
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000331212950.B2696@cygnus.com>
References: <003e01bf9b69$afc0c220$35758798@mis.amat.com> <38E538DF.ED6289D6@ozemail.com.au>
X-SW-Source: 2000-q1/msg00855.html
Content-length: 1359
On Sat, Apr 01, 2000 at 09:46:40AM +1000, David Williams wrote:
>Use -b command line option to change baud rate
>
>eg. gdb -b 115200
>to set baud rate 115200 baud.
>Dave.
Note that in some older versions of the Cygwin DLL (possibly in B20.1)
there was an error which caused the 115200 baud rate to be incorrectly
handled. Everything should work ok if you are using the Cygwin CD or if
you are using a later cygwin snapshot.
cgf
>Serge Nikulin wrote:
>> I use gdb for remote debugging of m68k target, compiled with MRI
>> <--host=i686-pc-cygwin32 --target=m68k-motorola-ieee>
>> Native MRI' X-Ray debugger does not support our home-made RTOS.
>> GDB works but I have few questions.
>>
>> 1) Currently ieee-695 bfd section is not connected to gdb, so I work without
>> src.
>> I've checked examples of coff and aout conections and it does not look
>> as a 1-day job for me
>> (including the fact that ieee-695 support in bfd is incomplete).
>> Does anyone have ieee + gdb experience?
>>
>> 2) In my gdb session under WinNT I use command "target remote com1"
>> In this case gdb connects to COM1 at 9600 baud. I'd like to change this
>> speed (say, to 38400) but I can't. I've changed default speed for COM1 in
>> WinNT's control panel but it did not help. It looks like I have to pass that
>> speed to cygwin.dll somehow. How can I do that?
From jason-gdb@molenda.com Sat Apr 01 00:00:00 2000
From: Jason Molenda <jason-gdb@molenda.com>
To: gdb@sourceware.cygnus.com
Subject: Re: gdb and iso-c
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000325110517.A15903@shell17.ba.best.com>
X-SW-Source: 2000-q1/msg00808.html
Content-length: 777
Both Tom Tromey and I have brought this up before, but I'll bring
it up again. automake includes a program (ansi2knr) which is able
to reformat ISO C code in to K&R code -- it would not be difficult
to incorporate this (without switching to automake, even; just add
it in) for targets that do not have an ISO C compiler and for which
we cannot expect the presence of the GNU tools.
I'm in favor of moving to ISO C. It's been around a very long
time, we can move forward. But the cost of supporting older systems
via an automated translation at compile-time is so low that it is
silly to not add in support for it.
Of course, I'm not volunteering to actually _add_ the support for it
myself. :-) I need to start finding more free time somewhere. :-/
My two cents,
Jason
From mark@codesourcery.com Sat Apr 01 00:00:00 2000
From: Mark Mitchell <mark@codesourcery.com>
To: Peter.Schauer@Regent.E-Technik.TU-Muenchen.DE
Cc: kingdon@redhat.com, donnte@microsoft.com, gdb@sourceware.cygnus.com
Subject: Re: Regressions problem (200 failures)
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000302090343I.mitchell@codesourcery.com>
References: <20000302023420H.mitchell@codesourcery.com> <200003021143.MAA14294@reisser.regent.e-technik.tu-muenchen.de>
X-SW-Source: 2000-q1/msg00511.html
Content-length: 502
>>>>> "Peter" == Peter Schauer <Peter.Schauer@Regent.E-Technik.TU-Muenchen.DE> writes:
Peter> with GCC or GDB), a breakpoint on the opening brace is not
Peter> what I want, as I will almost always have to step over it.
Peter> I'd expect a breakpoint on the first local variable that
Peter> needs initalization, or the first statement.
Yes, I think we're all agreed.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
From msnyder@cygnus.com Sat Apr 01 00:00:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: hjl@lucon.org, gdb@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: Problems with hardware watchpoint on ia32.
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38D7DEE7.47D8@cygnus.com>
References: <20000307132401.A20282@valinux.com> <200003081008.FAA16481@indy.delorie.com> <20000308084304.A3150@lucon.org> <200003091211.HAA19860@indy.delorie.com>
X-SW-Source: 2000-q1/msg00763.html
Content-length: 2108
Eli Zaretskii wrote:
>
> Problem no.2: Read watchpoints break when they shouldn't.
Accepted and checked in. --michael
> Example (slightly modified test program posted by H.J. Lu):
>
> $ cat wp.c
> int a1;
> int a2;
> int a3;
> int a4;
> int a5;
> int a6;
>
> unsigned long long ulla1 = 0;
> double da2 = 0;
>
> int main (void)
> {
> a2 = 12;
> a3 = 13;
> a4 = 14;
> a5 = 15;
> a6 = 16;
> a1 = 11;
> a2 = a4;
>
> ulla1 = 0x00000000ffffffffLL;
> da2 = 12;
> ulla1 = 0xffffffff00000000LL;
>
> return 0;
> }
>
> $ gcc -g -o wp wp.c
> $ gdb wp
> (gdb) watch a5
> Hardware watchpoint 2: a5
> (gdb) rwatch a5
> Hardware read watchpoint 3: a5
> (gdb) run
> Starting program g:/gdbsnap/gdb-0222/gdb/wp
> Hardware watchpoint 2: a5
>
> Old value = 0
> New value = 15
> Hardware read watchpoint 3: a5
>
> Value = 15
> main () at wp.c: 16
> 16 a5 = 15;
> (gdb)
>
> Now, it might seem like a strange idea to put two watchpoints on the
> same variable, but it is a very useful feature when each watchpoint
> has a different condition.
>
> Here's the patch:
>
> 2000-03-08 Eli Zaretskii <eliz@is.elta.co.il>
>
> * breakpoint.c (bpstat_stop_status): Don't stop if a read
> watchpoint appears to break, but the watched value changed.
>
> --- gdb/breakpoint.c~2 Wed Mar 8 19:20:28 2000
> +++ gdb/breakpoint.c Wed Mar 8 20:02:20 2000
> @@ -2620,6 +2620,17 @@ bpstat_stop_status (pc, not_a_breakpoint
> /* Stop. */
> break;
> case WP_VALUE_CHANGED:
> + if (b->type == bp_read_watchpoint)
> + {
> + /* Don't stop: read watchpoints shouldn't fire if
> + the value has changed. This is for targets which
> + cannot set read-only watchpoints. */
> + bs->print_it = print_it_noop;
> + bs->stop = 0;
> + continue;
> + }
> + ++(b->hit_count);
> + break;
> case WP_VALUE_NOT_CHANGED:
> /* Stop. */
> ++(b->hit_count);
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Jim Blandy <jimb@cygnus.com>, gdb@sourceware.cygnus.com
Subject: Re: multi-arch notes (long); Was: Multi-arching tm_print_insn?
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38B4848F.CBF6CDE@cygnus.com>
References: <200002232238.RAA28167@zwingli.cygnus.com> <38B481C5.D10C1F52@cygnus.com>
X-SW-Source: 2000-q1/msg00393.html
Content-length: 26820
Oops,
There was a reason for changing the subject line. I've attatched some
old notes.\x18\x13
Andrew
Target specific commands.
Some *-tdep.c files define target specific commands (the mips-tdep.c
has plenty of examples). If we start adding all of those commands in
then we will get caos.
Choices are:
o delete them
o make them context sensative
(Don't mode me in.) so that they
are only applicable when the
relevant target is active
o re-do the syntax to be target
specific (vis `sim *' that exists
today).
================================================================
Shared library support and target VS host confusion.
A number of valid targets only build native:
hppa1.1-hp-hpux native somsolib.[hc] require native files
hppa1.1-hp-hpux10.20 native ditto
hppa1.1-hp-hpux10.30 native ditto
hppa1.1-hp-hpux11.00 native ditto
hppa1.1-hp-hpux9 native ditto
sparc-sun-solaris2 native Problems with procfs
sparc-sun-sunos native Problems in solib.c
In all cases the problem comes about because the shared library code
assumes that certain headers/functions are present on the build
machine. Long term this should be fixed (however, this will be very
long term).
In the case of these targets the shared library code is also hobbled
by containing certain target specific conditionals. Shared library
support as a target specific issue is complex a shared library
mechansim tends to depend on both the target architecture and the
object file format.
================================================================
Subject: Sketch of OO issues for multi-arch
Date: 21 Oct 1998 08:15:42 -0700
From: (Andrew Cagney)
Organization: Cygnus Solutions news/mail gateway
To:
Newsgroups:
[This should be sgml'd or some-such]
Background.
Part of the multi-arch support within GDB is moving the target
architecture vectors away from hardwired code to a more OO like
arrangement.
A pragmatic restriction on GDB is that it be compilable with an ISO C
compiler so much of the framework being discussed below is required as
a mechanism that works around the lack of an OO language :-)
The status quo:
[Ref: devo/gdb/config/mips/tm-*]
The MIPS tm-*.h files probably best illustrate the two very similar
(but subtly different) techniques being used to build up target-arch
descriptions in the current GDB.
The first technique is to include a fairly generic mips/tm-*.h file
which provides fairly broad mips target definitions and then refine a
subset of those definitions to match the specific mips target of
interest.
The second technique (effectively the reverse of the first) is to
define some target specific macro and then include other tm-* files
which fill in missing parts using the target specific information.
[Ref: devo/gdb/*-tdep.c]
In addition to the target definitions, a target specific *-tdep.c file
is built. Along with a number of target specific functions, this file
contains static pool of target-arch specific variables.
Finally, this file, using the __initialize* function, initialize any
complicated local objects.
Stages:
(Just a reminder)
The initial multi-arch implementation will only allow one
architectural instance at any time. Consequently the first multi-arch
work will not need to worry about parameterizing all architecture
methods with the current architecture. That will be implemented in a
later stage.
Eg:
void f (int parm);
vs void f (struct target *, int parm);
The proposals:
Overview (no surprises here):
Per the architecture document, all target specific architectural
information is moved into a struct. Macro's that were previously
hard-wired to a specific targets definition are replaced with function
calls (via the struct) to the currently selected target code.
Detail - is it in here?
Initialization - registering a target-arch
Both bfd/ and opcodes/ contain a hardwired table of known
architectures customized (using #ifdef) for the toolchain being build.
sim/common/ in a similar fashion has a hardwired table of known
devices.
GDB, on the other hand, for the target-remote modules, uses a
`registrary' approach - each target-remote remote-*.c file registers
its interface during initialization.
My experience from sim/common/ + sim/ppc/ suggests that for
target-arch the target-remote registrary approach would be best.
Each *-tdep.c target-arch would register itself as being responsible
for one or more BFD archures.
Initialization - creating target-arch structures.
Each target may have associated with it a significant number of
architectural variants (For the MIPS, I've lost count!) and each of
these variants would need a separate, different, target-arch
structure.
Several mechanisms for creating these architectures were considered:
making them static; creating them all at initialization time; creating
them on-demand.
The last is to be used. Only when a user selects a target-arch
(implicitly with `file ...', explicitly with `set architecture ..')
will the full target-arch struct be created an populated.
The registrary would also track which target-arch structures have
already been created - thus avoiding duplication.
Creation - inheritance by stealth
As noted in the intro, the existing tm-*.h mechanism uses #include
along with #ifdef and #undef#define to create static target-arch
inheritance. (tm-vr5000.h inherits tm-mips64.h inherits tm-mips.h?).
In a similar fashion, a given target-arch struct will be created by the
more specific architecture code first obtaining a target-arch struct
from a less specific architecture and then refining it to the specific
targets needs.
For instance, we would expect to see either of the initialization
sequences:
vr5000:
obj = create mips-64
refine vr5000 aspects of obj
mips-64:
obj = create mips
refine 64 bit aspects of obj
mips:
obj = create obj
refine mips aspects of obj
and:
vr5000:
obj = create mips
refine mips-64 aspects of obj
refine vr5000 aspects of obj
(`refine mips-64 aspects of obj' would be an operation common to a
number of mips targets).
[Nothing original here, sim/common/ implements this successfully. The
two alternatives roughly correspond to the techniques currently being
used by the existing tm-*.h #include maze]
Method invocation:
Some of the target-arch struct members will be function pointers vis:
struct target_arch {
..
int (*arch_op) (struct target_arch *, int parm);
..
}
The `arch_op' being invoked using the mechanism:
arch->arch_op (arch, ...);
For convenience, macro's (I could make them functions) will be
available that simplify this vis:
#define ARCH_OP(a,p) (a)->arch_op ((a), p)
Notice that I've shown ARCH_OP parameterized with the current
architecture.
During the initial phase, ARCH_OP's definition will not be fully
parameterized vis:
extern struct target_arch target_arch;
#define ARCH_OP(p) (target_arch->arch_op) (p)
For optional functions, a predicate such as ``ARCH_OP_P(a)'' will be
available:
if (ARCH_OP_P ())
ARCH_OP (arg);
Pragmatics: In the longer term, when methods are parameterized with
their object, simplistic macros such as `#define ARCH_OP
(target_arch->arch_op)' which allow tests like if(ARCH_OP) will be
broken.
[Don't stake your life on my naming schema, don't stake your life on
that parameter]
target-arch specific data:
Some target-arch methods use external data (such as the target-remote
or the register file).
Since, initially, only one target can be active at any time this isn't
an issue.
Longer term, when everything becomes parameterized, there will be a
need to pass into target-arch methods the target-vector et.al. objects
that they are to act on.
It may turn out to be easier to have a single object that contains
each of the current target-specific comonents vis:
struct target {
...
struct target_arch *arch;
struct target_remote *remote;
...
}
each target-arch method parameterized with this super object.
[Note: this is an observation of an issue and not a commitment to a
specific solution].
================================================================
Date: Tue, 27 Oct 1998 15:33:46 +1100 (WET)
From: Andrew Cagney <>
To: The Wet Fish <>
Subject: Possible multi-arch testing extension ...
Hello,
This provides an overview of an additional work item that could be added
to the multi-arch GDB project.
The current intention is to test multi-arch functionality by extending
the existing GDB testsuite with a single multi-arch test. That test
would put GDB through its paces in a very rudimentary way - simply
confirming that the same GDB was capable of talking to several different
targets.
Orthogonal to this is the suggestion that the GDB testsuite be modified
so that it can be used to run the full testsuite for all (some sub-set)
of compiled in GDB targets. It's important to note several issues this
possibility raises:
o The overall build environment isn't geared
up for this.
For instance, only a single target (or target) group
are supported by GCC.
Consequently to fully exercise a multi-arch GDB
a number of pre-installed compilers would be needed.
A typical test-run would continue to be focused
on a specific target.
o There are two ways of covering the arch-X-test matrix.
arch-X-test: for all arch ; do for all test ; do ...
and
test-X-arch: for all test; do for all arch ; do ...
Provided the testing framework allows you to limit
a test-run to a specific test or a specific target these
two alternatives are pretty much equivalent.
So.
The additional work item is to investigate ways of changing the GDB test
framework so that it allows the running of the full testsuite against a
number of targets. newlib may well prove to be a useful source of
idea's.
At the conclusion of this work, a single GDB binary could be
demonstrated running the full testsuite for two different architectures.
For the moment I'll treat this as `further work'.
================================================================
Simulators.
Only one builtin simulator target will be supported. This project is
not about supporting multiple internal simulators.
Multiple simulator targets from a single gdb will, eventually, be
supported through the use of separate simulator programs and a remote
serial protocol.
This isn't part of the initial work-plan and is left as a things to
do.
----------------------------------------------------------------
CALL_DUMMY, FIX_CALL_DUMMY, CALL_DUMMY_START_OFFSET,
CALL_DUMMY_LOCATION, PC_IN_CALL_DUMMY et.al.
GDB has two very different mechanisms for implementing inferior
function calls - the old (a bunch of macro's including CALL_DUMMY) and
the new (see blockframe.c).
Key among the differences are: saving the current context locally
instead of on the target stack; and restarting by setting the PC to
the function entry point instead of hacking up a dummy function call
somewhere in the target memory.
Multi-arch must support both - trying to rewrite the old is not within
the scope of this project.
Changes required - the new code is a `done'. The old code will
require the migration of macro's out of inferior.h into valops.c.
CALL_DUMMY_LOCATION should be changed to an enum; CALL_DUMMY needs to
be a char*; SIZEOF_CALL_DUMMY needed; ...
----------------------------------------------------------------
@item BELIEVE_PCC_PROMOTION
@item BELIEVE_PCC_PROMOTION_TYPE
Minor changes required.
coffread.c - the #if can be replaced with an if()else. defs.h - a
default value of zero should be provided. stabsread.c - the suplying
of a default value should be moved to defs.h, the #if mess should be
re-aranged to a set of if()else.
----------------------------------------------------------------
@item CPLUS_MARKER
Changes required.
Since almost all uses of CPLUS_MARKER appear as an initialization
element of static array's the first thought is to replace those static
arrays with dynamic ones. Further investigation, however, suggests
that it will be easier to just rewrite the code using those arrays to
explicitly test against the CPLUS_MARKER character.
cp-valprint.c - Need to rewrite the test in cp_is_vtbl_ptr_type() so
that it explictily tests for CPLUS_MARKER=='.'. Better might be to
use that common struct.
demangle.c - rewrite is_cplus_marker() to test for c==CPLUS_MARKER
explicitily.
Long term, since this is dynamic, there is no reason for not adding a
command to gdb so that the user can set/query it. Might even serve as
an excuse for the demangle.c tweeks that need to be made.
----------------------------------------------------------------
@item DECR_PC_AFTER_BREAK et.al.
No changes required.
In the short term this can just be another target variable. In the
longer term it would probably be a good idea to push this whole
problem into the target so that GDB never knows about post breapoint
pc decrementing.
----------------------------------------------------------------
@item EXTRA_FRAME_INFO
@item INIT_EXTRA_FRAME_INFO
@item INIT_FRAME_PC_FIRST
@item INIT_FRAME_PC
Changes required.
Per target data being stored in `struct frame_info'. In OO terms, a
target specific frame object inheriting from the generic frame_info
object.
Will need to replace that data with a reference to target specific
data. Will need functions for all those INIT_*FRAME* operations.
----------------------------------------------------------------
@item GCC_COMPILED_FLAG_SYMBOL
@item GCC2_COMPILED_FLAG_SYMBOL
Changes required.
Make these target specific pointers. symtab.h - delete the default
definitions of *_COMPILED_FLAG_SYMBOL.
----------------------------------------------------------------
@item GDB_TARGET_IS_HPPA
@item GDB_TARGET_IS_MACH386
@item GDB_TARGET_IS_SUN3
@item GDB_TARGET_IS_SUN386
@item IBM6000_TARGET
Later, much later.
These will be the first against the wall when the revolution comes.
Or, to put it another way, we'll wear these until they can be deleted
at the end of multi-arch conversion.
----------------------------------------------------------------
@item GET_LONGJMP_TARGET
Changes required.
Delete default definition of GET_LONGJMP_TARGET from infrun.c. Add a
function that returns a default value. Always implement
GET_LONGJMP_TARGET for all *-tdep.c's.
Will encounter namespace problems - get_longjmp_target() is overloaded
-> need to rename target specific versions of this function.
----------------------------------------------------------------
@item IN_SOLIB_TRAMPOLINE pc name
This is dead. It was replaced by:
@item IN_SOLIB_CALL_TRAMPOLINE
@item IN_SOLIB_RETURN_TRAMPOLINE
----------------------------------------------------------------
@item KERNEL_DEBUGGING
Later. This is for an obscure (well I think it is) target that will
hopefully allow everything to go away.
----------------------------------------------------------------
@item NO_HIF_SUPPORT
Later. This is for an obscure target.
----------------------------------------------------------------
@item PC_REGNUM
@item PS_REGNUM
@item TARGET_WRITE_PC et.al.
@item NPC_REGNUM
@item NNPC_REGNUM
@item MAX_REGISTER_RAW_SIZE
@item REGISTER_VIRTUAL_TYPE
@item NUM_REGS
@item MAX_REGISTER_VIRTUAL_SIZE
@item REGISTER_RAW_SIZE
@item REGISTER_VIRTUAL_SIZE
@item REGISTER_BYTE
@item PRINT_REGISTER_HOOK (regno)
Arrrrh. Ah, that feels better.
Date: Mon, 26 Oct 1998 16:44:25 +1100 (WET)
From: Andrew Cagney <>
To:
Subject: registers part of target-arch object
[With additional edits]
An FYI more than anything.
Most of the architecture specific code is `static' in that it doesn't
change for a given target.
Select a specific architecture and one can define a set of functions
that describe that architecture's functionality.
The quirk with this is the `register set'. At present targets describe
registers in an implementation specific way - the target-arch's assume
that GDB has some physical block of of memory that contains all
registers.
In adding multi-arch support I've two alternatives:
o stick with this existing code (at least
in the short term).
o come up with some new and exciting
register description.
My intention is to stick with the existing code. In particular:
o have each target architecture continue to describe
registers at this implementation specific way.
This limits the potential damage to all the target
config/*/tm-* that will need converting.
o bind the register data 1-1 to the target architecture
it belongs to. This limits GDB to one active instance
of a specific target. (GDB can't simultaneously to
several physical targets of the same architecture
aka unrestricted mixed-arch support).
This limits the potential damage to the generic
gdb register code (such as valops.c).
The consequences of the second point are especially important:
o It leaves GDB with the restriction of an architecture
being bound to a single physical target at any time.
(VS actively debugging several targets each with
the same architecture.)
o It doesn't stop GDB being attached to several
physical targets, each with a different architecture.
o It doesn't stop GDB being modified so that a
target architecture contains an internal mechanism
that switchs between target interfaces.
It is only that externally there appears to be a single
register interface.
o It doesn't attempt to address the issue of how the
overall GDB architecture should be should be changed
that it fully supports mixed-architectures.
That issue is beyond the scope of the current work.
The overall consequences are:
o limited collateral damage
We're not trying to rewrite the register code
at the same time as we introduce multi-arch.
o register re-design becomes feasible
Once the multi-arch framework is in place
significant cross-architecture changes such
as a new register mechanism become feasible.
o mixed-arch unhindered.
As per the revised multi-arch objectives:
``The objective is to add multi-arch support in a way
that doesn't hinder the following goals [multi-arch]''
We've made significant improvements without
commiting ourselves to a specific mixed-arch design.
================================================================
Turns out that defining TARGET_{FETCH,STORE}_PC does not oblivate the
need for PC_REGNUM. See write_register_gen.
parse.c:std_regs[]. Hmm, this should just be thrown back at the
target. For moment just disable it...
I think value_ptr should go!
GET_SAVED_REGISTER should define the function to call not just flip
the code.
enum target_signal doesn't get correctly exposed for everything to work.
================================================================
Phase two:
VARIABLES_INSIDE_BLOCK: Only sparc and convex.
SUN_FIXED_LBRAC_BUG: Only sparc/m78k.
PCC_SOL_BROKEN: Only convex
DISABLE_UNSETTABLE_BREAK: I some config/*/tm-*.h's are including
"solib.h" which is in turn defining DISABLE_UNSETTABLE_BREAK. An
example of this is tm-sunos.h. Interestingly, many config/nm-*.h's
also include "solib.h" which suggests that shared library support as a
pure target operation isn't quite there yet. :-(. In the long run, a
revamping of the shared library stuff so that it is truely based on
the selected target is needed, in the mean time, limiting shared
library to single-arch GDB's will be easier.
================================================================
Phase three:
SYMBOL_RELOADING_DEFAULT: Delete. No longer defined in current
sources.
SHIFT_INST_REGS: Only used by *old* m88k targets. Called from infrun.c
and infcmd.c. In both cases it can probably be re-vamped so that it
totally goes away.
PROLOGUE_FIRSTLINE_OVERLAP: This is only applicable to the convex
target which we don't even try to build!
BREAKPOINT, BIG_BREAKPOINT, LITTLE_BREAKPOINT: Delete this, replace
them with BREAKPOINT_FROM_PC.
REMOTE_BREAKPOINT, BIG_REMOTE_BREAKPOINT, LITTLE_REMOTE_BREAKPOINT:
Targets that use this are not supported (sh, m68k, h830).
USE_STRUCT_CONVENTION: Function of type use_struct_convention_fn.
PRINT_TYPELESS_INTEGER: Don't bother fixing this one.
OS9K_VARIABLES_INSIDE_BLOCK: I think that this is dead.
PC_LOAD_SEGMENT: Specific xcoff (rs6000). Is actually an object file
macro. Should be re-written so that all object file handlers provide
a similar module.
CORE_ADDR: This does not specify a type that exactly fits a target
address. Consequently, a 64 bit unsigned integer will be sufficient,
in the short term, as the CORE_ADDR address. Longer term we want some
sort of object.
CHILL_PRODUCER, GCC_PRODUCER, GPLUS_PRODUCER, LCC_PRODUCER: These
macro's don't have anything to do with the target. Rather they are
concerned with object file formats and and identifying characteristics
of same. Perhaphs they are better placed in BFD?
END_OF_TEXT_DEFAULT: This macro is really specific to the GOULD
architecture. It may well be possible to put this off until when it
isn't needed.
================================================================
Not documented:
MAX_REGISTER_RAW_SIZE
REGISTER_VIRTUAL_TYPE
NUM_REGS
VALUE_OF_TRAPPED_INTERNALVAR
CALL_DUMMY_START_OFFSET
FRAME_ARGS_SKIP
MAX_REGISTER_VIRTUAL_SIZE
REGISTER_RAW_SIZE
REGISTER_VIRTUAL_SIZE
REGISTER_BYTE
SET_TRAPPED_INTERNALVAR
FRAME_ARGS_ADDRESS
FRAME_LOCALS_ADDRESS
FIX_CALL_DUMMY
STORE_STRUCT_RETURN
SAVED_PC_AFTER_CALL
================================================================
Check list:
Registers
Types
Call Dummy
Registrary
A0_REGNUM
A2_REGNUM
A3_REGNUM
ADDR_BITS_REMOVE
AS_PROC_NAME_FMT
ATTACH_DETACH
BADVADDR_REGNUM
BELIEVE_PCC_PROMOTION
BIG_ENDIAN
BPT_ELEM_SZ
BREAKPOINT_FROM_PC
BROKEN_SIGINFO_H
CALL_DUMMY
CALL_DUMMY_ADDRESS
CALL_DUMMY_BREAKPOINT_OFFSET
CALL_DUMMY_LENGTH
CALL_DUMMY_LOCATION
CALL_DUMMY_START_OFFSET
CANNOT_STORE_REGISTER
CAUSE_REGNUM
CHILD_PREPARE_TO_STORE
CHILD_SPECIAL_WAITSTATUS
COERCE_FLOAT_TO_DOUBLE
CONVERT_FROM_FUNC_PTR_ADDR
CPLUS_MARKER
CR_REGNUM
CTL_PROC_NAME_FMT
CTR_REGNUM
D2_REGNUM
D3_REGNUM
DECR_PC_AFTER_BREAK
DEFAULT_LR_SAVE
DEFAULT_MIPS_TYPE
DEFAULT_PROMPT
DO_REGISTERS_INFO
DWARF_REG_TO_REGNUM
Dest_Reg
E0_REGNUM
ECOFF_REG_TO_REGNUM
ELF_MAKE_MSYMBOL_SPECIAL
ELF_OBJECT_FORMAT
EXTRACT_RETURN_VALUE
EXTRACT_STRUCT_VALUE_ADDRESS
EXTRA_FRAME_INFO
FAULTED_USE_SIGINFO
FCRCS_REGNUM
FCRIR_REGNUM
FETCH_INFERIOR_REGISTERS
FIFO_BPT_CNT
FIFO_BPT_TBL
FIRST_COP0_REG
FIRST_EMBED_REGNUM
FIRST_SP_REGNUM
FIRST_VEC_REG
FIVE_ARG_PTRACE
FIX_CALL_DUMMY
FP0_REGNUM
FPA0_REGNUM
FPLAST_REGNUM
FP_REGNUM
FRAMELESS_FUNCTION_INVOCATION
FRAME_ARGS_ADDRESS
FRAME_ARGS_SKIP
FRAME_CHAIN
FRAME_CHAIN_VALID
FRAME_CHAIN_VALID_ALTERNATE
FRAME_FIND_SAVED_REGS
FRAME_LOCALS_ADDRESS
FRAME_NUM_ARGS
FRAME_SAVED_PC
FUNCTION_START_OFFSET
GDBINIT_FILENAME
GDB_COMM_AREA
GDB_COMM_SIZE
GDB_TARGET_IS_MIPS64
GDB_TARGET_MASK_DISAS_PC
GDB_TARGET_POWERPC
GDB_TARGET_UNMASK_DISAS_PC
GET_LONGJMP_TARGET
GET_SAVED_REGISTER
GP0_REGNUM
HANDLE_SVR4_EXEC_EMULATORS
HAVE_NONSTEPPABLE_WATCHPOINT
HAVE_SIGSETMASK
HAVE_TERMIO
HAVE_TERMIOS
HI_REGNUM
HOST_BYTE_ORDER
IBM6000_TARGET
IEEE_FLOAT
IGNORE_HELPER_CALL
INIT_EXTRA_FRAME_INFO
INIT_FRAME_PC
INIT_FRAME_PC_FIRST
INNER_THAN
IN_SIGTRAMP
IN_SOLIB_CALL_TRAMPOLINE
IN_SOLIB_RETURN_TRAMPOLINE
IS_MIPS16_ADDR
JB_ELEMENT_SIZE
JB_G1
JB_NPC
JB_O0
JB_ONSSTACK
JB_PC
JB_PSR
JB_SIGMASK
JB_SP
JB_WBCNT
KERNEL_U_ADDR
KERNEL_U_SIZE
LAR_REGNUM
LAST_DEVICE
LAST_EMBED_REGNUM
LAST_SP_REGNUM
LIR_REGNUM
LO_REGNUM
LR_REGNUM
LSEEK_NOT_LINEAR
MACHINE_CPROC_FP_OFFSET
MACHINE_CPROC_PC_OFFSET
MACHINE_CPROC_SP_OFFSET
MAKE_MIPS16_ADDR
MAP_PROC_NAME_FMT
MAX_REGISTER_RAW_SIZE
MAX_REGISTER_VIRTUAL_SIZE
MDR_REGNUM
MIPS16_INSTLEN
MIPS_DEFAULT_FPU_TYPE
MIPS_EABI
MIPS_EFI_SYMBOL_NAME
MIPS_FPU_DOUBLE_REGSIZE
MIPS_FPU_SINGLE_REGSIZE
MIPS_INSTLEN
MIPS_LAST_ARG_REGNUM
MIPS_LAST_FP_ARG_REGNUM
MIPS_NUMREGS
MIPS_NUM_ARG_REGS
MIPS_REGSIZE
MQ_REGNUM
MSYMBOL_IS_SPECIAL
MSYMBOL_SIZE
NBPG
NM_NEWS_MIPS_H
NM_RS6000LYNX_H
NULL
NUM_COP0_REGS
NUM_CORE_REGS
NUM_REGS
NUM_VIF_REGS
NUM_VU_INTEGER_REGS
NUM_VU_REGS
ONE_PROCESS_WRITETEXT
OP_LDFPR
OP_LDGPR
PCB_OFFSET
PC_IN_CALL_DUMMY
PC_LOAD_SEGMENT
PC_REGNUM
POP_FRAME
PRID_REGNUM
PRINT_EXTRA_FRAME_INFO
PROCESS_LINENUMBER_HOOK
PRSVADDR_BROKEN
PSW_REGNUM
PS_REGNUM
PTRACE_ARG3_TYPE
PTRACE_ATTACH
PTRACE_DETACH
PUSH_ARGUMENTS
PUSH_DUMMY_FRAME
PUSH_RETURN_ADDRESS
R5900_128BIT_GPR_HACK
RA_REGNUM
REGISTER_BYTE
REGISTER_BYTES
REGISTER_CONVERTIBLE
REGISTER_CONVERT_FROM_TYPE
REGISTER_CONVERT_TO_RAW
REGISTER_CONVERT_TO_TYPE
REGISTER_CONVERT_TO_VIRTUAL
REGISTER_NAMES
REGISTER_NAME_ALIAS_HOOK
REGISTER_RAW_SIZE
REGISTER_SIZE
REGISTER_U_ADDR
REGISTER_VIRTUAL_SIZE
REGISTER_VIRTUAL_TYPE
REG_STRUCT_HAS_ADDR
REQUEST_QUIT
ROOTED_P
SAVED_BYTES
SAVED_FP
SAVED_PC
SAVED_PC_AFTER_CALL
SETPGRP_ARGS
SETUP_ARBITRARY_FRAME
SIGCONTEXT_PC_OFFSET
SIGFRAME_BASE
SIGFRAME_FPREGSAVE_OFF
SIGFRAME_PC_OFF
SIGFRAME_REGSAVE_OFF
SIGFRAME_REG_SIZE
SIGWINCH_HANDLER
SIGWINCH_HANDLER_BODY
SIG_FRAME_FP_OFFSET
SIG_FRAME_LR_OFFSET
SIG_FRAME_PC_OFFSET
SKIP_PROLOGUE
SKIP_TRAMPOLINE_CODE
SLASH_CHAR
SLASH_P
SLASH_STRING
SOFTWARE_SINGLE_STEP
SOFTWARE_SINGLE_STEP_P
SOFUN_ADDRESS_MAYBE_MISSING
SOLIB_ADD
SOLIB_CREATE_INFERIOR_HOOK
SP_REGNUM
SR_REGNUM
STAB_REG_TO_REGNUM
STACK_END_ADDR
START_INFERIOR_TRAPS_EXPECTED
STATIC_TRANSFORM_NAME
STATUS_PROC_NAME_FMT
STEP_SKIPS_DELAY
STEP_SKIPS_DELAY_P
STOPPED_BY_WATCHPOINT
STORE_RETURN_VALUE
STORE_STRUCT_RETURN
T9_REGNUM
TABULAR_REGISTER_OUTPUT
TARGET_BYTE_ORDER
TARGET_BYTE_ORDER_SELECTABLE
TARGET_CAN_USE_HARDWARE_WATCHPOINT
TARGET_HAS_HARDWARE_WATCHPOINTS
TARGET_KEEP_SECTION
TARGET_LONG_BIT
TARGET_LONG_LONG_BIT
TARGET_MIPS
TARGET_MN10300
TARGET_MONITOR_PROMPT
TARGET_PTR_BIT
TARGET_READ_FP
TARGET_READ_PC
TARGET_READ_SP
TARGET_REDEFINE_DEFAULT_OPS
TARGET_SYMFILE_POSTREAD
TARGET_VIRTUAL_FRAME_POINTER
TARGET_WRITE_FP
TARGET_WRITE_SP
TEXT_SEGMENT_BASE
TM_MIPS_H
TM_PPCLE_EABI_H
TM_PPCLE_SIM_H
TM_PPC_AIX_H
TM_PPC_EABI_H
TM_PPC_NW_H
TM_PPC_SIM_H
TM_PRINT_INSN_MACH
TM_RS6000LYNX_H
TM_RS6000_AIX4_H
TM_TXVU_H
TOC_REGNUM
TRACE_CLEAR
TRACE_FLAVOR
TRACE_FLAVOR_SIZE
TRACE_SET
TXVU_CPU_NUM
TXVU_SET_CPU_HELP_STRING
TXVU_VIF_BRK_MASK
TXVU_VU_BRK_MASK
UNMAKE_MIPS16_ADDR
UNUSED_REGNUM
UPAGES
USE_GENERIC_DUMMY_FRAMES
USE_O_NOCTTY
USE_PROC_FS
USE_STRUCT_CONVENTION
USG
U_REGS_OFFSET
V0_REGNUM
VIF0_PC_REGNUM
VIF1_PC_REGNUM
VU0_PC_REGNUM
VU0_RA_REGNUM
VU0_SP_REGNUM
VU1_PC_REGNUM
VU1_RA_REGNUM
VU1_SP_REGNUM
VX_NUM_REGS
XER_REGNUM
XM_RS6000LYNX_H
ZERO_REGNUM
_BSD_COMPAT
setpgrp
target_insert_watchpoint
target_remove_watchpoint
vfork
From eliz@delorie.com Sat Apr 01 00:00:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: Pierre Muller <muller@cerbere.u-strasbg.fr>
Cc: gdb@sourceware.cygnus.com, Elena Zannoni <ezannoni@cygnus.com>
Subject: Re: Buffering problems with "gdb < foo"
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003070851.DAA14463@indy.delorie.com>
References: <200003070845.JAA27855@cerbere.u-strasbg.fr>
X-SW-Source: 2000-q1/msg00558.html
Content-length: 675
> dir needs no confirmation if not invoked from tty !
Did you actually look at the from_tty variable's value inside
dir_command? I don't have the GDB 5.0 binary here, but GDB certainly
*does* ask for confirmation if invoked with stdin and stdout
redirected, at least in the DJGPP version. Elena, is that a bug?
Anyway, the basic point is still valid, even if this particular
example is not: when stdin is redirected to a file, GDB should turn
editing off.
> I think its because y is not a valid GDB command !
Invalid commands don't cause GDB to exit, they just result in an error
message. It would be inconceivable to have GDB exit every time I
mistype a command ;-).
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Jim Kingdon <kingdon@redhat.com>, gdb@sourceware.cygnus.com
Subject: Re: New file gdb/CONTRIBUTE guidelins for the contributor
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38A5FA15.CA467765@cygnus.com>
References: <38A3B39A.D3C7650C@cygnus.com> <38A3780F.2FE7A510@cygnus.com> <bg0v08f69.fsf@rtl.cygnus.com> <200002111929.OAA13997@mescaline.gnu.org>
X-SW-Source: 2000-q1/msg00247.html
Content-length: 719
Eli Zaretskii wrote:
>
> Andrew Cagney writes:
>
> > > So having said all that, do you still want submit.html or equivalent
> > > in the distribution? Having it both places seems like kind of a
> > > maintenance pain and seems to me that having the distribution point
> > > to the web site probably works.
> >
> > Yes, I think the GDB distribution should contain the document.
>
> Perhaps it is better to make this document part of the GDB manual.
> Then we could be sure it won't be forgotten due to changing fortunes
> of time...
In the end that could well prove to be the best place for it. I'd
prefer to have something in the top directory though so that we can
avoid the RTFM response :-)
enjoy,
Andrew
From totohero@poppy.snu.ac.kr Sat Apr 01 00:00:00 2000
From: "Lim, Sung-taek" <totohero@poppy.snu.ac.kr>
To: "crossgcc mailinglist" <crossgcc@sourceware.cygnus.com>, <gdb@sourceware.cygnus.com>
Subject: Breakpoint problem when running on gdb-4.18 arm/thumb simulator target
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <001401bf5db1$10157720$8f742e93@snu.ac.kr>
X-SW-Source: 2000-q1/msg00026.html
Content-length: 839
I built gdb-4.18 as arm (or thumb) target and tested a simple program which
was
compiled with arm-elf(or thumb-elf) target cross gcc. gdb abnormally exits
running
the program when reached any breakpoint. Internally gdb replaces instruction
at the breakpoint with another instruction which represents it's breakpoint
but
actually arm instruction simulator decoded it as undefined instruction or
undefined
kind of software interrupt. So we modified it and generated patch file which
includes
additional modification. (unfortunately I don't know much about it which was
done
by another member of our work group) Any kind of advice is welcome.
the patch can be found at:
http://poppy.snu.ac.kr/~totohero/arm-linux/gdb-4.18-dal-patch
(any other better place?)
--
Lim, Sung-taek
totohero@poppy.snu.ac.kr
http://poppy.snu.ac.kr/~totohero/
^ permalink raw reply [flat|nested] 3+ messages in thread