From mboxrd@z Thu Jan 1 00:00:00 1970 From: "H . J . Lu" To: Mark Kettenis Cc: jtc@redback.com, shebs@apple.com, gdb@sourceware.cygnus.com Subject: Re: A patch for gnu-regex Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <20000308155733.A4677@lucon.org> References: <38C585BB.3F7B1AC7@apple.com> <20000307155806.A30106@valinux.com> <5mg0u2l3g0.fsf@jtc.redbacknetworks.com> <20000307162127.D485@lucon.org> <200003080044.e280iGB00429@delius.kettenis.local> <5m4saivyew.fsf@jtc.redbacknetworks.com> <20000307211842.C1573@lucon.org> <5mvh2yugpy.fsf@jtc.redbacknetworks.com> <20000308091030.B3150@lucon.org> <200003081758.SAA17064@landau.wins.uva.nl> X-SW-Source: 2000-q1/msg00630.html 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 * gdb_regex.h: New. Include 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 ], +[#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 #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 +#else +#include "gnu-regex.h" +#endif +#endif /* _GDB_REGEX_H */ >From eliz@delorie.com Sat Apr 01 00:00:00 2000 From: Eli Zaretskii 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 > > * 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 To: Brent Weech 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 To: David Williams Cc: Serge Nikulin , 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 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 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 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 To: Eli Zaretskii 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 > > * 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 To: Jim Blandy , 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. 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 To: Pierre Muller Cc: gdb@sourceware.cygnus.com, Elena Zannoni 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 To: Eli Zaretskii Cc: Jim Kingdon , 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> <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" To: "crossgcc mailinglist" , 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/