* Re: GDB manual and @smallbook [not found] <200003031956.OAA23859@delysid.gnu.org> @ 2000-03-20 16:36 ` Stan Shebs 2000-04-01 0:00 ` Brian Youmans 0 siblings, 1 reply; 2+ messages in thread From: Stan Shebs @ 2000-03-20 16:36 UTC (permalink / raw) To: Brian Youmans; +Cc: gdb-patches I don't remember responding to this, but in case I haven't, I am actually working on these problems, should be done in a day or two. Stan Brian Youmans wrote: > > I'm afraid this isn't going to constitute a .diff, but here are > problems that I noted with the file version I downloaded. > > What I ended up downloading was the latest version of gdb.texinfo > and of all-cfg.texinfo from your CVSWeb interface. These I combined > with old versions of the readline doc (so I won't comment on that part yet). > > What is the next version going to be - 4.19, or 5.0? > > - Brian Y., FSF office staff > > ------------------ > > The ISBN where listed should be 1-882114-77-9. > > I would prefer having the line > "Printed copies are available for $20 each." > eliminated (so that we can change the price someday). > > ------------------ > > Line 1172: > tracepoints -- Tracing of program execution without stopping the program > > This is too long for @smallbook format. Break after "stopping" with a "\"? > > ------------------ > > line 1892-4: > > * 3 system thread 26607 worker (wptr=0x7b09c318 "@@") at quicksort.c:137 > 2 system thread 26606 0x7b0030d8 in __ksleep () from /usr/lib/libc.2 > 1 system thread 27905 0x7b003498 in _brk () from /usr/lib/libc.2 > > Too long. Replace @example with @smallexample? > Still a little long, but maybe we can live with it. > > ------------------ > > line 6972: > Values of time mode locations are represented by @code{TIME(<secs>:<nsecs>)}. > > Too long. > > ------------------ > > line 7421: > "/home/smith/cc_progs/a.out": can't open to read symbols: Invalid bfd target. > > Too long - replace @example with @smallexample? > Again, still long - break somehow? > > ------------------ > line 8757: > > @tab @code{A}@var{arglen}@code{,}@var{argnum}@code{,}@var{arg}@code{,...} > > Too long - break somehow. > > ------------------ > > line 9180: > > @item @code{N}@var{AA}@code{;}@var{tttttttt}@code{;}@var{dddddddd}@code{;}@var{bbbbbbbb} @strong{(obsolete)} > > Too long - break somehow. > > ------------------ > > line 9199-9223: > > Parts of this multitable just don't work in @smallbook. @multitable > and @smallbook don't mix well. If you want to keep the multitable, > perhaps someone could redo this section and make a patch for use when > @smallbook is used? > > I will complain to RMS and the Texinfo maintainer about this. > > ------------------ > > line 9249: > > @item > @tab reply @code{Text=}@var{xxx}@code{;Data=}@var{yyy}@code{;Bss=}@var{zzz} > > Too long - need to be broken. > > ------------------ > > line 9262: > > @item remote command > @tab @code{q}@code{Rcmd,}@var{COMMAND} > > Too long - need to be broken. > > ------------------ From kevinb@cygnus.com Mon Mar 20 16:44:00 2000 From: Kevin Buettner <kevinb@cygnus.com> To: gdb-patches@sourceware.cygnus.com Subject: [PATCH RFA] gdbserver/low-linux.c changes for IA-64 Date: Mon, 20 Mar 2000 16:44:00 -0000 Message-id: <1000321004346.ZM20197@ocotillo.lan> X-SW-Source: 2000-03/msg00398.html Content-length: 6307 I seek approval for checking in the following changes: * gdbserver/low-linux.c (u_offsets, ia64_register_u_addr, initialize_arch): Define for IA-64. Index: low-linux.c =================================================================== RCS file: /cvs/src/src/gdb/gdbserver/low-linux.c,v retrieving revision 1.1.1.6 diff -u -p -r1.1.1.6 low-linux.c --- low-linux.c 1999/12/08 02:50:48 1.1.1.6 +++ low-linux.c 2000/03/21 00:36:06 @@ -274,6 +274,284 @@ m68k_linux_register_u_addr (blockend, re { return (blockend + 4 * regmap[regnum]); } +#elif defined(IA64_GNULINUX_TARGET) +#undef NUM_FREGS +#define NUM_FREGS 0 + +#include <asm/ptrace_offsets.h> + +static int u_offsets[] = + { + /* general registers */ + -1, /* gr0 not available; i.e, it's always zero */ + PT_R1, + PT_R2, + PT_R3, + PT_R4, + PT_R5, + PT_R6, + PT_R7, + PT_R8, + PT_R9, + PT_R10, + PT_R11, + PT_R12, + PT_R13, + PT_R14, + PT_R15, + PT_R16, + PT_R17, + PT_R18, + PT_R19, + PT_R20, + PT_R21, + PT_R22, + PT_R23, + PT_R24, + PT_R25, + PT_R26, + PT_R27, + PT_R28, + PT_R29, + PT_R30, + PT_R31, + /* gr32 through gr127 not directly available via the ptrace interface */ + -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, + -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, + -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, + -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, + -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, + -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, + /* Floating point registers */ + -1, -1, /* f0 and f1 not available (f0 is +0.0 and f1 is +1.0) */ + PT_F2, + PT_F3, + PT_F4, + PT_F5, + PT_F6, + PT_F7, + PT_F8, + PT_F9, + PT_F10, + PT_F11, + PT_F12, + PT_F13, + PT_F14, + PT_F15, + PT_F16, + PT_F17, + PT_F18, + PT_F19, + PT_F20, + PT_F21, + PT_F22, + PT_F23, + PT_F24, + PT_F25, + PT_F26, + PT_F27, + PT_F28, + PT_F29, + PT_F30, + PT_F31, + PT_F32, + PT_F33, + PT_F34, + PT_F35, + PT_F36, + PT_F37, + PT_F38, + PT_F39, + PT_F40, + PT_F41, + PT_F42, + PT_F43, + PT_F44, + PT_F45, + PT_F46, + PT_F47, + PT_F48, + PT_F49, + PT_F50, + PT_F51, + PT_F52, + PT_F53, + PT_F54, + PT_F55, + PT_F56, + PT_F57, + PT_F58, + PT_F59, + PT_F60, + PT_F61, + PT_F62, + PT_F63, + PT_F64, + PT_F65, + PT_F66, + PT_F67, + PT_F68, + PT_F69, + PT_F70, + PT_F71, + PT_F72, + PT_F73, + PT_F74, + PT_F75, + PT_F76, + PT_F77, + PT_F78, + PT_F79, + PT_F80, + PT_F81, + PT_F82, + PT_F83, + PT_F84, + PT_F85, + PT_F86, + PT_F87, + PT_F88, + PT_F89, + PT_F90, + PT_F91, + PT_F92, + PT_F93, + PT_F94, + PT_F95, + PT_F96, + PT_F97, + PT_F98, + PT_F99, + PT_F100, + PT_F101, + PT_F102, + PT_F103, + PT_F104, + PT_F105, + PT_F106, + PT_F107, + PT_F108, + PT_F109, + PT_F110, + PT_F111, + PT_F112, + PT_F113, + PT_F114, + PT_F115, + PT_F116, + PT_F117, + PT_F118, + PT_F119, + PT_F120, + PT_F121, + PT_F122, + PT_F123, + PT_F124, + PT_F125, + PT_F126, + PT_F127, + /* predicate registers - we don't fetch these individually */ + -1, -1, -1, -1, -1, -1, -1, -1, + -1, -1, -1, -1, -1, -1, -1, -1, + -1, -1, -1, -1, -1, -1, -1, -1, + -1, -1, -1, -1, -1, -1, -1, -1, + -1, -1, -1, -1, -1, -1, -1, -1, + -1, -1, -1, -1, -1, -1, -1, -1, + -1, -1, -1, -1, -1, -1, -1, -1, + -1, -1, -1, -1, -1, -1, -1, -1, + /* branch registers */ + PT_B0, + PT_B1, + PT_B2, + PT_B3, + PT_B4, + PT_B5, + PT_B6, + PT_B7, + /* virtual frame pointer and virtual return address pointer */ + -1, -1, + /* other registers */ + PT_PR, + PT_CR_IIP, /* ip */ + PT_CR_IPSR, /* psr */ + PT_CR_IFS, /* cfm */ + /* kernel registers not visible via ptrace interface (?) */ + -1, -1, -1, -1, -1, -1, -1, -1, + /* hole */ + -1, -1, -1, -1, -1, -1, -1, -1, + PT_AR_RSC, + PT_AR_BSP, + PT_AR_BSPSTORE, + PT_AR_RNAT, + -1, + -1, /* Not available: FCR, IA32 floating control register */ + -1, -1, + -1, /* Not available: EFLAG */ + -1, /* Not available: CSD */ + -1, /* Not available: SSD */ + -1, /* Not available: CFLG */ + -1, /* Not available: FSR */ + -1, /* Not available: FIR */ + -1, /* Not available: FDR */ + -1, + PT_AR_CCV, + -1, -1, -1, + PT_AR_UNAT, + -1, -1, -1, + PT_AR_FPSR, + -1, -1, -1, + -1, /* Not available: ITC */ + -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, + -1, -1, -1, -1, -1, -1, -1, -1, -1, + PT_AR_PFS, + PT_AR_LC, + -1, /* Not available: EC, the Epilog Count register */ + -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, + -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, + -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, + -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, + -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, + -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, + -1, + /* nat bits - not fetched directly; instead we obtain these bits from + either rnat or unat or from memory. */ + -1, -1, -1, -1, -1, -1, -1, -1, + -1, -1, -1, -1, -1, -1, -1, -1, + -1, -1, -1, -1, -1, -1, -1, -1, + -1, -1, -1, -1, -1, -1, -1, -1, + -1, -1, -1, -1, -1, -1, -1, -1, + -1, -1, -1, -1, -1, -1, -1, -1, + -1, -1, -1, -1, -1, -1, -1, -1, + -1, -1, -1, -1, -1, -1, -1, -1, + -1, -1, -1, -1, -1, -1, -1, -1, + -1, -1, -1, -1, -1, -1, -1, -1, + -1, -1, -1, -1, -1, -1, -1, -1, + -1, -1, -1, -1, -1, -1, -1, -1, + -1, -1, -1, -1, -1, -1, -1, -1, + -1, -1, -1, -1, -1, -1, -1, -1, + -1, -1, -1, -1, -1, -1, -1, -1, + -1, -1, -1, -1, -1, -1, -1, -1, + }; + +int +ia64_register_u_addr (int blockend, int regnum) +{ + int addr; + + if (regnum < 0 || regnum >= NUM_REGS) + error ("Invalid register number %d.", regnum); + + addr = u_offsets[regnum]; + if (addr == -1) + addr = 0; + + return addr; +} + +initialize_arch() +{ + return; +} #endif CORE_ADDR ^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: GDB manual and @smallbook 2000-03-20 16:36 ` GDB manual and @smallbook Stan Shebs @ 2000-04-01 0:00 ` Brian Youmans 0 siblings, 0 replies; 2+ messages in thread From: Brian Youmans @ 2000-04-01 0:00 UTC (permalink / raw) To: shebs; +Cc: gdb-patches Thanks! Whenever there is a finished version of the manual that you don't really expect to change before the release, I'd like a copy, or just a pointer. We are out of stock, and it would be good to put this into print ASAP. - Brian Y., FSF office staff From eliz@delorie.com Sat Apr 01 00:00:00 2000 From: Eli Zaretskii <eliz@delorie.com> To: binutils@sourceware.cygnus.com Cc: gdb-patches@sourceware.cygnus.com Subject: [PATCH] libopcodes on MS-DOS Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200002270903.EAA25069@indy.delorie.com> X-SW-Source: 2000-q1/msg00378.html Content-length: 1513 The following changes handle two problems with building libbfd on 8+3 (a.k.a. DOS) filesystems. They get in the way when building with DJGPP tools. I found this while building the latest snapshot of GDB. 2000-02-26 Eli Zaretskii <eliz@is.elta.co.il> * aclocal.m4 (AC_SYS_NM_PARSE): Use mconftest.$objext, not conftestm.$objext, since the latter overwrites conftest.$objext on 8+3 filesystems. * Makefile.am (objdir): New variable, computed by running libtool. (stamp-lib): Use objdir instead of a literal .libs. --- bfd/aclocal.m~0 Sun Aug 8 18:21:52 1999 +++ bfd/aclocal.m4 Sat Feb 26 16:25:46 2000 @@ -662,10 +662,10 @@ #endif EOF # Now try linking the two files. - mv conftest.$ac_objext conftestm.$ac_objext + mv conftest.$ac_objext mconftest.$ac_objext ac_save_LIBS="$LIBS" ac_save_CFLAGS="$CFLAGS" - LIBS="conftestm.$ac_objext" + LIBS="mconftest.$ac_objext" CFLAGS="$CFLAGS$no_builtin_flag" if AC_TRY_EVAL(ac_link) && test -s conftest; then ac_pipe_works=yes --- bfd/Makefile.a~0 Mon Feb 21 07:54:20 2000 +++ bfd/Makefile.am Sat Feb 26 20:40:24 2000 @@ -474,10 +474,11 @@ noinst_LIBRARIES = libbfd.a libbfd_a_SOURCES = +objdir = `$(LIBTOOL) --config | sed -n -e s,^objdir=,,p` stamp-lib: libbfd.la - if [ -f .libs/libbfd.a ]; then \ - cp .libs/libbfd.a libbfd.tmp; \ + if [ -f $(objdir)/libbfd.a ]; then \ + cp $(objdir)/libbfd.a libbfd.tmp; \ $(SHELL) $(srcdir)/../move-if-change libbfd.tmp libbfd.a; \ else true; fi touch stamp-lib From kettenis@wins.uva.nl Sat Apr 01 00:00:00 2000 From: Mark Kettenis <kettenis@wins.uva.nl> To: gdb-patches@sourceware.cygnus.com Subject: [PATCH] Make cross-compilation for the Hurd a bit more friendly Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200002261349.e1QDn3604520@delius.kettenis.local> X-SW-Source: 2000-q1/msg00371.html Content-length: 1742 Hi, FYI, I checked in the following patch: 2000-02-26 Mark Kettenis <kettenis@gnu.org> Make cross-compilation for the Hurd more friendly. From Jeff Bailey <jbailey@gnu.org>: * configure.in: Use AC_CHECK_TOOL to find MiG. * Makefile.in (MIG): New variable. * config/i386/i386gnu.mh (MIG): Remove. * configure: Regenerated. Index: gdb/configure.in =================================================================== RCS file: /cvs/src/src/gdb/configure.in,v retrieving revision 1.7 diff -u -r1.7 configure.in --- gdb/configure.in 2000/02/24 08:16:26 1.7 +++ gdb/configure.in 2000/02/26 13:31:55 @@ -77,6 +77,9 @@ AC_CHECK_TOOL(RANLIB, ranlib, :) AC_PROG_YACC +dnl MiG is needed for the Hurd. +AC_CHECK_TOOL(MIG, mig) + AC_ARG_PROGRAM AC_TYPE_SIGNAL Index: gdb/Makefile.in =================================================================== RCS file: /cvs/src/src/gdb/Makefile.in,v retrieving revision 1.8 diff -u -r1.8 Makefile.in --- gdb/Makefile.in 2000/02/24 08:16:26 1.8 +++ gdb/Makefile.in 2000/02/26 13:31:57 @@ -59,6 +59,7 @@ RANLIB = @RANLIB@ DLLTOOL = @DLLTOOL@ WINDRES = @WINDRES@ +MIG = @MIG@ # If the user configured GDB to include the TUI, the name of the tui # library goes here. Index: gdb/config/i386/i386gnu.mh =================================================================== RCS file: /cvs/src/src/gdb/config/i386/i386gnu.mh,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 i386gnu.mh --- gdb/config/i386/i386gnu.mh 1999/04/16 01:34:18 1.1.1.1 +++ gdb/config/i386/i386gnu.mh 2000/02/26 13:31:57 @@ -12,7 +12,6 @@ msg-MIGUFLAGS = -D'MSG_IMPORTS=waittime 1000;' # ick -MIG = mig MIGCOM = $(MIG) -cc cat - /dev/null # Reply servers need special massaging of the code mig generates, to make From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney <ac131313@cygnus.com> To: GDB Patches <gdb-patches@sourceware.cygnus.com> Subject: [MAINT] Devolve responsibilities Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38C84733.C86136C9@cygnus.com> X-SW-Source: 2000-q1/msg00638.html Content-length: 1579 Just to close this, I've committed the attatched. Andrew Fri Mar 10 11:44:55 2000 Andrew Cagney <cagney@b1.cygnus.com> * MAINTAINERS: Devolve responsibility for domain maintenance. Index: MAINTAINERS =================================================================== RCS file: /cvs/src/src/gdb/MAINTAINERS,v retrieving revision 1.22 diff -p -r1.22 MAINTAINERS *** MAINTAINERS 2000/03/09 03:32:09 1.22 --- MAINTAINERS 2000/03/10 00:41:50 *************** Peter Schauer Peter.Schauer@regent.e-t *** 14,27 **** Note individuals who maintain parts of the debugger need approval to check in changes outside of the immediate domain that they maintain. ! If there is no maintainer for a given domain then the problem falls to ! the head maintainer. ! If there are several maintainers for a given domain then the problem ! falls to the first maintainer. The second and third maintainers are ! firstly known to have expertise in the given domain and secondly are ! available to step in if the first maintainer is to be absent for any ! reason. Target/Architecture: --- 14,25 ---- Note individuals who maintain parts of the debugger need approval to check in changes outside of the immediate domain that they maintain. ! If there is no maintainer for a given domain then the responsibility ! falls to the head maintainer. ! If there are several maintainers for a given domain then ! responsibility falls to the first maintainer. The first maintainer is ! free to devolve that responsibility among the other maintainers. Target/Architecture: From dan@cgsoftware.com Sat Apr 01 00:00:00 2000 From: dan@cgsoftware.com (Daniel Berlin+list.gdb-patches) To: Jimmy Guo <guo@cup.hp.com> Cc: gdb-patches@sourceware.cygnus.com Subject: Re: patch: regression: C++ overload Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <ya796sox.fsf@dan.resnet.rochester.edu> References: <Pine.LNX.4.10.10003231828220.10977-100000@hpcll168.cup.hp.com> X-SW-Source: 2000-q1/msg00965.html Content-length: 417 Jimmy Guo <guo@cup.hp.com> writes: Yeah, i screwed that one accidently in the overload fixes, when diagnosing the original problem. Fixed and committed. --Dan > This patch fixes a regression in gdb introduced some time between 1/10 > and 3/21. The symptom of it is unitialized memory reference in > valops.c (find_overload_match). This patch backs out a couple of > bad changes. > > - Jimmy Guo, guo@cup.hp.com From shebs@apple.com Sat Apr 01 00:00:00 2000 From: Stan Shebs <shebs@apple.com> To: dan@cgsoftware.com Cc: gdb-patches@sourceware.cygnus.com, Fernando Nasser <fnasser@cygnus.com> Subject: Re: [RFA]: Apropos patch Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38D9815A.FC4E178E@apple.com> References: <1z52tswd.fsf@dan.resnet.rochester.edu> X-SW-Source: 2000-q1/msg00931.html Content-length: 961 "Daniel Berlin+list.gdb-patches" wrote: > > It includes documentation, a test case (which uses a slightly weird > regexp so it only finds one thing, and we make sure it only found one > thing), and all the apropriate changelog entries. You're going to hate this, but now that I see the example in the manual, I'm wondering why "prefix:" and "command:" are on separate lines? Why not just imitate the syntax that comes out of the help command - set symbol-reloading -- <help string> show symbol-reloading -- <help string> Another advantage is that users can then cut-n-paste from the apropos output more easily. > Let me know if i can check it in, i believe it needs approval from > Stan Shebs, and Fernando Nasser. Just needs approval from one of us, not both! I must confess to being a bit mystified by the test though - why use "handle" as the match string, and do I understand right, you're requiring that it be the first output from apropos? Stan From dima@Chg.RU Sat Apr 01 00:00:00 2000 From: Dmitry Sivachenko <dima@Chg.RU> To: kettenis@wins.uva.nl, shebs@shebs.cnchost.com Cc: dima@Chg.RU, eliz@is.elta.co.il, gdb-patches@sourceware.cygnus.com Subject: Re: patch for gdb.texinfo Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200001301814.VAA59965@netserv1.chg.ru> References: <200001281909.e0SJ97M18034@delius.kettenis.local> X-SW-Source: 2000-q1/msg00049.html Content-length: 2016 > > (Hi everybody!) > > Welcome back Stan! > > Dmitry Sivachenko wrote: > > > I think we should use new features of texinfo. May be in future > > versions typeseting @env and @command will differ from the > > current behaviour. By the way, FreeBSD team already updated > > texinfo to 4.0 in base distribution. > > I disagree here. We do have to worry about backward compatibility, > just as we had to support K&R compilers for a long time, and just > as we support many old OS versions. Certainly many GDB users would > be disappointed if we trashed Linux support for any kernel older > than, say, 2.2.5! > > Well, it's slightly more complicated than that. > > It is standard GNU procedure to include the info files in the > distribution. So the user doesn't need makeinfo when building from an > official release. It is also standard procedure to include > texinfo.tex in the distribution, thus for making a printed manual an > up-to-date texinfo isn't necessary either. > > Thus someone who isn't actively hacking on package doesn't need texinfo at > all. > > Cygnus might do things a little different. Is GDB still distributed > with texinfo included? The CVS version suggests that this is the > case. Since the version in CVS is older than texinfo 4.0, using new > features would not be very convenient! Maybe it is time for an > upgrade? Because I think that if using new feature improves the > markup we should try to use them. > Oh, I noticed /texinfo directory in your repository :). Well, why not to upgrade texinfo there and use new texinfo commands--- no fuss, no muss... By the way, this looks odd. If everybody think that new commands (@env and @command, in our case) are useless, we should write to authors of texinfo and discuss it there. But if these commands do exist, why not to use them? May be somewhere in the future, they will be marked up differently, or W3C introduce new tag <ENV>, which will be used when producing HTML output, etc. --dima From scottb@netwinder.org Sat Apr 01 00:00:00 2000 From: Scott Bambrough <scottb@netwinder.org> To: GDB Patches Mail List <gdb-patches@sourceware.cygnus.com> Subject: RFA: patch to gdb.base/long_long.exp Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38B6A12D.5E0C35C7@netwinder.org> X-SW-Source: 2000-q1/msg00367.html Content-type: multipart/mixed; boundary="----------=_1583534363-29877-27" This is a multi-part message in MIME format... ------------=_1583534363-29877-27 Content-length: 576 This test prints a long long as a double, and then compares the output to a floating point number. Due to the different memory layout of doubles on the ARM it fails. This patch special cases the test for ARM platforms. If this is ok, let me know and I will check it in. 2000-02-25 Scott Bambrough <scottb@netwinder.org> * gdb.base/long_long.exp: Correct test suite failure when printing a long long value as a double on ARM platforms. -- Scott Bambrough - Software Engineer REBEL.COM http://www.rebel.com NetWinder http://www.netwinder.org long_long.exp.diff ------------=_1583534363-29877-27 Content-Type: text/x-diff; charset=us-ascii; name="long_long.exp.diff" Content-Disposition: inline; filename="long_long.exp.diff" Content-Transfer-Encoding: base64 Content-Length: 928 SW5kZXg6IGxvbmdfbG9uZy5leHANCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0N ClJDUyBmaWxlOiAvY3ZzL3NyYy9zcmMvZ2RiL3Rlc3RzdWl0ZS9nZGIuYmFz ZS9sb25nX2xvbmcuZXhwLHYNCnJldHJpZXZpbmcgcmV2aXNpb24gMS4xLjEu NQ0KZGlmZiAtdSAtcCAtcjEuMS4xLjUgbG9uZ19sb25nLmV4cA0KLS0tIGxv bmdfbG9uZy5leHAJMTk5OS8wOS8xMyAyMTozODoyMwkxLjEuMS41DQorKysg bG9uZ19sb25nLmV4cAkyMDAwLzAyLzI1IDE1OjE2OjQ0DQpAQCAtMTIxLDEx ICsxMjEsMjAgQEAgZ2RiX3Rlc3QgInAvYyBvY3QiICIuKid3Jy4qIg0KIA0K IGlmIHsgJHNpemVvZl9kb3VibGUgPT0gOCB9IHsNCiANCisgIGlmIFsgaXN0 YXJnZXQgImFybSotKi0qIiBdIHRoZW4gew0KKw0KKyAgICAgZ2RiX3Rlc3Qg InAvZiBvY3QiICIuKjIuMTM4NjY3NjM1NDM4NzU1OWVcXCsyNjUuKiINCisN CisgIH0gZWxzZSB7DQorDQogICAgIGdkYl90ZXN0ICJwL2Ygb2N0IiAiLiot NS45ODIyNjUzNzk3NjE1NzIzZS0xMjAuKiINCiANCisgIH0NCisNCiB9IGVs c2Ugew0KIA0KICAgICBnZGJfdGVzdCAicC9mIG9jdCIgIi4qLTIuNDI3MTYx MjZlLTE1LioiDQorDQogfQ0KIA0KIGlmIHsgJHRhcmdldF9iaWdlbmRpYW5f cCB9IHsNCg== ------------=_1583534363-29877-27-- From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney <ac131313@cygnus.com> To: gdb-patches@sourceware.cygnus.com Subject: ISO-C fixes in, please try Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38C1D692.26606328@cygnus.com> X-SW-Source: 2000-q1/msg00514.html Content-length: 236 Hello, I think I've eliminated all the glaring ISO-C fixes needed (there are still many warnings but they can be flushed post 5.0). If people had trouble building with a non GCC ISO-C compiler, could they please re-try. Andrew From eliz@delorie.com Sat Apr 01 00:00:00 2000 From: Eli Zaretskii <eliz@delorie.com> To: ac131313@cygnus.com Cc: gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH] Add change-log variables to more MI files Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003140932.EAA28159@indy.delorie.com> References: <38CDC788.D9C8FE12@cygnus.com> X-SW-Source: 2000-q1/msg00688.html Content-length: 373 > I've checked in the attatched. It should help keep ChangeLog entries > local. [snip] > + > + # Local variables: > + # change-log-default-name: "ChangeLog-mi" > + # End: You _are_ aware that ChangeLog and ChangeLog-mi both map to the same name "changelo" when truncated to 8+3 limits, right? Is it conceivable to rename ChangeLog-mi to ChangeLog.mi or mi-ChangeLog? From Franz.Sirl-kernel@lauterbach.com Sat Apr 01 00:00:00 2000 From: Franz Sirl <Franz.Sirl-kernel@lauterbach.com> To: gdb-patches@sourceware.cygnus.com Subject: Small testsuite fix Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <00032922114503.03866@enzo.bigblue.local> X-SW-Source: 2000-q1/msg01110.html Content-length: 1013 Hi, the appended patch fixes a testsuite problem on platforms that default a char to 'unsigned char' like Linux/PPC. Franz. * gdb.base/structs2.c: Support platforms defaulting to a unsigned char. Index: gdb/testsuite/gdb.base/structs2.c =================================================================== RCS file: /cvs/src/src/gdb/testsuite/gdb.base/structs2.c,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 structs2.c --- structs2.c 1999/04/16 01:34:32 1.1.1.1 +++ structs2.c 2000/03/29 20:06:15 @@ -1,6 +1,6 @@ /* pr 13536 */ -static void param_reg (register char pr_char, +static void param_reg (register signed char pr_char, register unsigned char pr_uchar, register short pr_short, register unsigned short pr_ushort); @@ -25,7 +25,7 @@ main () static void dummy () {} static void -param_reg(register char pr_char, +param_reg(register signed char pr_char, register unsigned char pr_uchar, register short pr_short, register unsigned short pr_ushort) From eliz@delorie.com Sat Apr 01 00:00:00 2000 From: Eli Zaretskii <eliz@delorie.com> To: toddpw@windriver.com Cc: jtc@redback.com, hjl@valinux.com, gdb-patches@sourceware.cygnus.com, gdb@sourceware.cygnus.com Subject: Re: A patch for ia32 hardware watchpoint. Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003091328.IAA19934@indy.delorie.com> References: <200003080845.AAA18410@alabama.wrs.com> X-SW-Source: 2000-q1/msg00615.html Content-length: 1307 > As far as I'm concerned, passing the breakpoint pointer is the right way > to go; we should get away from the assumption that a target side breakpoint > is an address with some #define'd size, and push that stuff into a default > implementation that can be invoked easily by people writing new target > support. I agree. But if we do that, I'd also suggest to leave it to the target to decide whether a particular watchpoint fired or not. Right now, the API presented by GDB is based solely on the address: bpstat_stop_status calls target_stopped_data_address and does all the decision-making based solely on that address (and some info it keeps internally about each watchpoint). This API is extremely limited. Typically, the target knows much more about the watchpoint which triggered than the generic GDB code does, so it can make smarter decisions. But in order to do that, the target needs more information about the watchpoint, and it needs to pass back to GDB the result (whether the watchpoint triggered or not), not its address. Btw, if we let the target decide whether a given watchpoint triggered, we can also resolve, once and for all, all the various conflicts between target-specific limitations of hardware-assisted watchpoints, which now need to be dealt with on the generic level. From jtc@redback.com Sat Apr 01 00:00:00 2000 From: jtc@redback.com (J.T. Conklin) To: Andrew Cagney <ac131313@cygnus.com> Cc: Jim Kingdon <kingdon@redhat.com>, gdb-patches@sourceware.cygnus.com Subject: Re: Clean up compiler warnings Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <5mpuu87esc.fsf@jtc.redbacknetworks.com> References: <200002071950.OAA29599@devserv.devel.redhat.com> <389F583E.65831CE5@cygnus.com> X-SW-Source: 2000-q1/msg00089.html Content-length: 1253 >>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes: Andrew> When switching on an enum (as in this case) I've typically Andrew> found it better to explicitly list all cases rather than use a Andrew> default. That way, when a new element is added to the enum, Andrew> the -Wswitch warning is available as a tool to the programmer Andrew> to identify where code needs to be altered. As an aside, that Andrew> is why a switch on an enum rather than an if/elsif chain often Andrew> proves more resilient to long term maintenance. What happens when an enum gets assigned a value that's not in the set of elements? If there isn't a default case, we won't catch the error. For example: enum foo { RED, GREEN, BLUE } foo; ... foo = 10; /* bogus assignment */ ... switch (foo) { case RED: ...; break; case GREEN: ...; break; case BLUE: ...; break; } Without a default case, program flow will continue after the switch statement. With one, your -Wswitch trick won't work. I'm not sure which is worse. --jtc -- J.T. Conklin RedBack Networks From charles.gauthier@nrc.ca Sat Apr 01 00:00:00 2000 From: Charles-Antoine Gauthier <charles.gauthier@nrc.ca> To: gdb-patches@sourceware.cygnus.com Subject: GDB patch for 167Bug Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38C42988.2AE770D7@nrc.ca> X-SW-Source: 2000-q1/msg00546.html Content-length: 2398 Attached is a patch to allow GDB 4.18 to write to the MVME167 through 167Bug. The MS command does not work; the MW command must be used. The ChangeLog hunk has context from the RTEMS patches. It probably will not apply cleanly, but it is quite short. -- Charles-Antoine Gauthier Institute for Information Technology Institut de technologie de l'information National Research Council of Canada Conseil national de recherches du Canada *** gdb-4.18/gdb/167bug-rom.c Mon Mar 6 14:20:50 2000 --- ../gdb/gdb/167bug-rom.c Mon Mar 6 14:54:42 2000 *************** *** 110,118 **** m167bug_cmds.clr_break = "nobr %x\r"; /* clear a breakpoint */ m167bug_cmds.clr_all_break = "nobr\r"; /* clear all breakpoints */ m167bug_cmds.fill = "bf %x:%x %x;b\r"; /* fill (start count val) */ ! m167bug_cmds.setmem.cmdb = "ms %x %02x\r"; /* setmem.cmdb (addr, value) */ ! m167bug_cmds.setmem.cmdw = "ms %x %04x\r"; /* setmem.cmdw (addr, value) */ ! m167bug_cmds.setmem.cmdl = "ms %x %08x\r"; /* setmem.cmdl (addr, value) */ m167bug_cmds.setmem.cmdll = NULL; /* setmem.cmdll (addr, value) */ m167bug_cmds.setmem.resp_delim = NULL; /* setreg.resp_delim */ m167bug_cmds.setmem.term = NULL; /* setreg.term */ --- 110,118 ---- m167bug_cmds.clr_break = "nobr %x\r"; /* clear a breakpoint */ m167bug_cmds.clr_all_break = "nobr\r"; /* clear all breakpoints */ m167bug_cmds.fill = "bf %x:%x %x;b\r"; /* fill (start count val) */ ! m167bug_cmds.setmem.cmdb = "mw %x %02x;b\r"; /* setmem.cmdb (addr, value) */ ! m167bug_cmds.setmem.cmdw = "mw %x %04x;w\r"; /* setmem.cmdw (addr, value) */ ! m167bug_cmds.setmem.cmdl = "mw %x %08x;l\r"; /* setmem.cmdl (addr, value) */ m167bug_cmds.setmem.cmdll = NULL; /* setmem.cmdll (addr, value) */ m167bug_cmds.setmem.resp_delim = NULL; /* setreg.resp_delim */ m167bug_cmds.setmem.term = NULL; /* setreg.term */ *** gdb-4.18/gdb/ChangeLog Mon Mar 6 15:38:40 2000 --- ../gdb/gdb/ChangeLog Mon Mar 6 16:33:39 2000 *************** *** 1,3 **** --- 1,7 ---- + 2000-03-06 Charles-Antoine Gauthier <charles.gauthier@nrc.ca> + + * 167bug-rom.c(init_m167bug_cmds): Change the write commands. + Fri Aug 6 165:41:15 EDT 1999 Charles-A. Gauthier <charles.gauthier@iit.nrc.ca> * config/m68k/monitor.mt (TDEPFILES): Add 167bug-rom.o. From scottb@netwinder.org Sat Apr 01 00:00:00 2000 From: Scott Bambrough <scottb@netwinder.org> To: GDB Patches Mail List <gdb-patches@sourceware.cygnus.com> Subject: Re: Minor patches for ARM Linux native port... Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38BADABA.56541EA7@netwinder.org> References: <38BAD90A.FE163BDA@netwinder.org> X-SW-Source: 2000-q1/msg00403.html Content-length: 742 Scott Bambrough wrote: > > I've checked the following patch to arm-linux-nat.c in. This just cleans up > some build warnings and naming of functions. Oops. Pushed the send button by mistake. The patches are in config/arm/linux.mh and config/arm/tm-linux.h. These clean up build problems and warnings. > 2000-02-28 Scott Bambrough <scottb@netwinder.org> > > * config/arm/linux.mh (NATDEPFILES): Removed core-regset.o. > Not used. Required to get GDB to build on glibc 2.1.3. > * config/arm/tm-linux.h (LOWEST_PC): Undefine LOWEST_PC > before redefining. Gets rid of compiler warning. > -- Scott Bambrough - Software Engineer REBEL.COM http://www.rebel.com NetWinder http://www.netwinder.org From kingdon@redhat.com Sat Apr 01 00:00:00 2000 From: Jim Kingdon <kingdon@redhat.com> To: kettenis@wins.uva.nl Cc: gdb-patches@sourceware.cygnus.com Subject: Re: Patch to fix thread support for Solaris x86 Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200002280236.VAA19189@devserv.devel.redhat.com> References: <200002261228.NAA32377@reisser.regent.e-technik.tu-muenchen.de> <bem9ypm2a.fsf@rtl.cygnus.com> <38B9C737.BA89B057@cygnus.com> <200002280210.e1S2AdS25152@delius.kettenis.local> X-SW-Source: 2000-q1/msg00391.html Content-length: 1174 > Peter's patch has a small problem (for which I am probably to blame, > since it appears I suggested it): it conditionalizes the code on > HAVE_I387_REGS, which according to the following comment in > i386-tdep.c isn't right: We got slightly tangled up on Peter's HAVE_I387_REGS patch versus Peter's MERGEPID patch but that's minor, the point is that you are catching all kinds of things like this, Mark, and that's why I'd love to have you as a maintainer (speaking for myself; I guess Andrew is working through the process so I don't want to prejudge what he ends up with). > I have absolutely no experience with embedded targets. I have been > hacking on GDB for Hurd/i386 and Linux/i386, and I do have an old i486 > with FreeBSD installed. Sign that man up! ('up for what' I leave as an exercise to the reader :-)). > I think I have a basic understanding of the most important multi-arch > issues, but I would probably need some guidance if we ever go that > route for x86. Guidance should be doable. One application for at least some amount of multi-arch is so that a FreeBSD GDB can debug either a native binary or a Linux binary. I'm sure there are others. From shebs@apple.com Sat Apr 01 00:00:00 2000 From: Stan Shebs <shebs@apple.com> To: Andrew Cagney <ac131313@cygnus.com> Cc: Eli Zaretskii <eliz@is.elta.co.il>, gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH] Fix texinfo problems... Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38E171AC.AB1B5AD0@apple.com> References: <38DB1875.4B504618@cygnus.com> <38DBB937.126C95E@apple.com> <38DC6763.563424A2@cygnus.com> <200003260443.XAA26499@mescaline.gnu.org> <38E05161.9707ED26@cygnus.com> <38E1171F.7651C329@apple.com> <38E16AB4.F6081625@cygnus.com> X-SW-Source: 2000-q1/msg01101.html Content-length: 876 Andrew Cagney wrote: > > Stan Shebs wrote: > > > > I didn't see your message before doing my big commit this morning, > > so some of the changes are redundant. I would suggest updating > > from cvs over your patched file and seeing what's left over after > > the merge - the remainder should be much smaller... > > A patch to revert the remainder is attached. If you could go ahead and commit these, that would be great. Seeing them reminds me of why I had to take out the explicit links in the first place - they didn't play nice with the inserted readline docs, and would have required changes that couldn't have been accepted into standard readline. So I slashed through the Gordian knot of cross-links :-) by taking them all out... (Clearly my next round of checkins should include a note to future hackers about why the explicit links are not in there, eh?) Stan From shebs@apple.com Sat Apr 01 00:00:00 2000 From: Stan Shebs <shebs@apple.com> To: dan@cgsoftware.com Cc: gdb-patches@sourceware.cygnus.com Subject: Re: [RFC] Better apropos patch Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38D94FF8.2932EF67@apple.com> References: <Pine.LNX.4.10.10003221307320.20082-100000@propylaea.anduin.com> <38D9429B.798F82E2@redhat.com> <wvmufwx9.fsf@dan.resnet.rochester.edu> X-SW-Source: 2000-q1/msg00924.html Content-length: 451 "Daniel Berlin+list.gdb-patches" wrote: > I'll go finish commenting it, reformat it, add a changelog entry, and > add a texinfo entry in a few minutes. Please please please add a testcase or two also. I suggest at the end of gdb.base/help.exp, and lots of wildcarding in the match; but you can count on basic commands like "break" and "print" always being in GDB... This apropos command *will* be really nice to have! Thanks for adding it! Stan From fnasser@cygnus.com Sat Apr 01 00:00:00 2000 From: Fernando Nasser <fnasser@cygnus.com> To: gdb-patches@sourceware.cygnus.com Subject: RFA: Patches to configure.in and Makefile.in - varobj.c activation Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38AB216C.8C77477D@cygnus.com> X-SW-Source: 2000-q1/msg00207.html Content-length: 5688 ChangeLog: configure.in: Replaces obsolete gdbtk-variable.c with gdbtk-varobj.c. configure: Regenerate. Makefile.in: Remove obsolete/extraneous references to gdbtk-var* files. -- Fernando Nasser Red Hat - Toronto E-Mail: fnasser@cygnus.com 2323 Yonge Street, Suite #300 Tel: 416-482-2661 ext. 311 Toronto, Ontario M4P 2C9 Fax: 416-482-6299 Index: configure.in =================================================================== RCS file: /cvs/src/src/gdb/configure.in,v retrieving revision 1.3 diff -c -p -r1.3 configure.in *** configure.in 2000/02/16 13:42:25 1.3 --- configure.in 2000/02/16 22:10:46 *************** if test "${enable_gdbtk}" = "yes"; then *** 665,673 **** # were in LIBS then any link tests after this point would # try to include things like `$(LIBGUI)', which wouldn't work. GDBTKLIBS="${TCL_LIBS} ${TK_LIBS}" ! CONFIG_SRCS="${CONFIG_SRCS} gdbtk/generic/gdbtk.c gdbtk/generic/gdbtk-cmds.c gdbtk/generic/gdbtk-hooks.c gdbtk/generic/gdbtk-variable.c gdbtk/generic/gdbtk-wrapper.c" ! CONFIG_OBS="${CONFIG_OBS} gdbtk.o gdbtk-cmds.o gdbtk-hooks.o gdbtk-variable.o gdbtk-wrapper.o" ! CONFIG_INITS="${CONFIG_INITS} gdbtk/generic/gdbtk.c gdbtk/generic/gdbtk-cmds.c gdbtk/generic/gdbtk-hooks.c gdbtk/generic/gdbtk-variable.c gdbtk/generic/gdbtk-wrapper.c" if test x$gdb_cv_os_cygwin = xyes; then WIN32LIBS="${WIN32LIBS} -lshell32 -lgdi32 -lcomdlg32 -ladvapi32" --- 665,673 ---- # were in LIBS then any link tests after this point would # try to include things like `$(LIBGUI)', which wouldn't work. GDBTKLIBS="${TCL_LIBS} ${TK_LIBS}" ! CONFIG_SRCS="${CONFIG_SRCS} gdbtk/generic/gdbtk.c gdbtk/generic/gdbtk-cmds.c gdbtk/generic/gdbtk-hooks.c gdbtk/generic/gdbtk-varobj.c gdbtk/generic/gdbtk-wrapper.c" ! CONFIG_OBS="${CONFIG_OBS} gdbtk.o gdbtk-cmds.o gdbtk-hooks.o gdbtk-varobj.o gdbtk-wrapper.o" ! CONFIG_INITS="${CONFIG_INITS} gdbtk/generic/gdbtk.c gdbtk/generic/gdbtk-cmds.c gdbtk/generic/gdbtk-hooks.c gdbtk/generic/gdbtk-varobj.c gdbtk/generic/gdbtk-wrapper.c" if test x$gdb_cv_os_cygwin = xyes; then WIN32LIBS="${WIN32LIBS} -lshell32 -lgdi32 -lcomdlg32 -ladvapi32" Index: configure =================================================================== RCS file: /cvs/src/src/gdb/configure,v retrieving revision 1.3 diff -c -p -r1.3 configure *** configure 2000/02/16 22:01:29 1.3 --- configure 2000/02/16 22:10:49 *************** fi *** 6653,6661 **** # were in LIBS then any link tests after this point would # try to include things like `$(LIBGUI)', which wouldn't work. GDBTKLIBS="${TCL_LIBS} ${TK_LIBS}" ! CONFIG_SRCS="${CONFIG_SRCS} gdbtk/generic/gdbtk.c gdbtk/generic/gdbtk-cmds.c gdbtk/generic/gdbtk-hooks.c gdbtk/generic/gdbtk-variable.c gdbtk/generic/gdbtk-wrapper.c" ! CONFIG_OBS="${CONFIG_OBS} gdbtk.o gdbtk-cmds.o gdbtk-hooks.o gdbtk-variable.o gdbtk-wrapper.o" ! CONFIG_INITS="${CONFIG_INITS} gdbtk/generic/gdbtk.c gdbtk/generic/gdbtk-cmds.c gdbtk/generic/gdbtk-hooks.c gdbtk/generic/gdbtk-variable.c gdbtk/generic/gdbtk-wrapper.c" if test x$gdb_cv_os_cygwin = xyes; then WIN32LIBS="${WIN32LIBS} -lshell32 -lgdi32 -lcomdlg32 -ladvapi32" --- 6653,6661 ---- # were in LIBS then any link tests after this point would # try to include things like `$(LIBGUI)', which wouldn't work. GDBTKLIBS="${TCL_LIBS} ${TK_LIBS}" ! CONFIG_SRCS="${CONFIG_SRCS} gdbtk/generic/gdbtk.c gdbtk/generic/gdbtk-cmds.c gdbtk/generic/gdbtk-hooks.c gdbtk/generic/gdbtk-varobj.c gdbtk/generic/gdbtk-wrapper.c" ! CONFIG_OBS="${CONFIG_OBS} gdbtk.o gdbtk-cmds.o gdbtk-hooks.o gdbtk-varobj.o gdbtk-wrapper.o" ! CONFIG_INITS="${CONFIG_INITS} gdbtk/generic/gdbtk.c gdbtk/generic/gdbtk-cmds.c gdbtk/generic/gdbtk-hooks.c gdbtk/generic/gdbtk-varobj.c gdbtk/generic/gdbtk-wrapper.c" if test x$gdb_cv_os_cygwin = xyes; then WIN32LIBS="${WIN32LIBS} -lshell32 -lgdi32 -lcomdlg32 -ladvapi32" Index: Makefile.in =================================================================== RCS file: /cvs/src/src/gdb/Makefile.in,v retrieving revision 1.4 diff -c -p -r1.4 Makefile.in *** Makefile.in 2000/02/16 04:45:41 1.4 --- Makefile.in 2000/02/16 22:10:50 *************** SFILES = ax-general.c ax-gdb.c bcache.c *** 431,437 **** kod.c kod-cisco.c \ ui-out.c cli-out.c \ varobj.c wrapper.c \ - gdbtk-varobj.c \ jv-exp.y jv-lang.c jv-valprint.c jv-typeprint.c \ m2-exp.y m2-lang.c m2-typeprint.c m2-valprint.c main.c maint.c \ mem-break.c minsyms.c mipsread.c nlmread.c objfiles.c parse.c \ --- 431,436 ---- *************** gdbtk-hooks.o: $(srcdir)/gdbtk/generic/g *** 1261,1272 **** $(CC) -c $(INTERNAL_CFLAGS) $(IDE_CFLAGS) $(ITCL_CFLAGS) $(TIX_CFLAGS) \ $(TCL_CFLAGS) $(TK_CFLAGS) $(X11_CFLAGS) $(GDBTK_CFLAGS)\ $(srcdir)/gdbtk/generic/gdbtk-hooks.c -DGDBTK_LIBRARY=\"$(datadir)/gdbtcl\" - - gdbtk-variable.o: $(srcdir)/gdbtk/generic/gdbtk-variable.c \ - $(srcdir)/gdbtk/generic/gdbtk.h $(srcdir)/gdbtk/generic/gdbtk-wrapper.h - $(CC) -c $(INTERNAL_CFLAGS) $(IDE_CFLAGS) $(ITCL_CFLAGS) $(TIX_CFLAGS) \ - $(TCL_CFLAGS) $(TK_CFLAGS) $(X11_CFLAGS) $(GDBTK_CFLAGS)\ - $(srcdir)/gdbtk/generic/gdbtk-variable.c gdbtk-varobj.o: $(srcdir)/gdbtk/generic/gdbtk-varobj.c \ $(srcdir)/gdbtk/generic/gdbtk.h \ --- 1260,1265 ---- From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney <ac131313@cygnus.com> To: GDB Discussion <gdb@sourceware.cygnus.com> Cc: GDB Patches <gdb-patches@sourceware.cygnus.com> Subject: [MAINT/RFC] Start devolving maintenance responsibility Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38BC81A0.17D25C8@cygnus.com> X-SW-Source: 2000-q1/msg00436.html Content-length: 3150 Hello, GDB's been on sourceware for a whole month so its now probably time time to start devolving more responsibility :-) With that in mind, I'm proposing the attatched change. It hopefully achieves the following: o allows the maintainers within a domain to self organize o clearly identify who is ultimately responsible for a maintenace domain (where the buck stops :-) o provides a suggested fraomewor within which domain maintainers can work. Comments? I'm going to leave this tabled for at lest a week as I know of at least two maintainers that are off line right now. Andrew Wed Mar 1 12:29:35 2000 Andrew Cagney <cagney@b1.cygnus.com> * MAINTAINERS: Devolve responsibility for domain maintenance to the domain maintainers. ? diffs Index: ChangeLog =================================================================== RCS file: /cvs/src/src/gdb/ChangeLog,v retrieving revision 1.88 diff -p -r1.88 ChangeLog *** ChangeLog 2000/03/01 00:45:18 1.88 --- ChangeLog 2000/03/01 02:31:28 *************** *** 1,3 **** --- 1,8 ---- + Wed Mar 1 12:29:35 2000 Andrew Cagney <cagney@b1.cygnus.com> + + * MAINTAINERS: Devolve responsibility for domain maintenance to + the domain maintainers. + 2000-03-01 Mark Kettenis <kettenis@gnu.org> * MAINTAINERS: Correct my own mail address. Index: MAINTAINERS =================================================================== RCS file: /cvs/src/src/gdb/MAINTAINERS,v retrieving revision 1.16 diff -p -r1.16 MAINTAINERS *** MAINTAINERS 2000/03/01 00:45:18 1.16 --- MAINTAINERS 2000/03/01 02:31:31 *************** Stan Shebs shebs@cygnus.com *** 8,24 **** Various Maintainers ! Note individuals who maintain parts of the debugger need approval to ! check in changes outside of the immediate domain that they maintain. ! If there is no maintainer for a given domain then the problem falls to ! the head maintainer. ! If there are several maintainers for a given domain then the problem ! falls to the first maintainer. The second and third maintainers are ! firstly known to have expertise in the given domain and secondly are ! available to step in if the first maintainer is to be absent for any ! reason. Target/Architecture: --- 8,29 ---- Various Maintainers ! Individuals who make changes to the debugger need approval from all ! relevant domain maintainers before those changed can be checked in. ! If there is no maintainer for a given maintenance domain then approval ! is the responsibility of the head maintainer. ! If there are several maintainers for a given maintenance domain then ! approval is the responsibility of the first maintainer. How exactly ! that responsibility is administered is also the responsibility of the ! first maintainer. ! ! Typically, when there are several maintainers, the first maintainer ! will devolve all responsibility for that domain to that domains ! maintainers. Individuals making changes within their domain would ! have major changes approved through consensus (with their peers) while ! minor tweaks would not need approval. Target/Architecture: From msnyder@cygnus.com Sat Apr 01 00:00:00 2000 From: Michael Snyder <msnyder@cygnus.com> To: John Wehle <john@feith.com> Cc: cgf@cygnus.com, nsd@cygnus.com, eliz@delorie.com, jimb@cygnus.com, gdb-patches@sourceware.cygnus.com Subject: Re: GDB 4.17 Patch for stack aligned i386 code Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38DBE6AF.4A7B@cygnus.com> References: <200003242200.RAA13376@jwlab.FEITH.COM> X-SW-Source: 2000-q1/msg01004.html Content-length: 4117 John, Eli, Jim et al, Nick Duffek also recently did some work related to frameless function backtraces on the X86. I don't know whether his work is checked into the main trunk. I'd like to see him involved in this discussion, so that we don't wind up with two solutions to the same problem. Thanks, Michael John Wehle wrote: > > > Is it possible to tell a bit more about the problem, and how is it > > solved? > > It's desirable to omit the frame pointer when compiling leaf functions > when targeting the x86 processor as this provides another hard register > (%ebp) which can be used by the register allocators. Using > -momit-leaf-frame-pointer instructs GCC to compile code in this manner. > Unfortunately GDB has a rather strong belief that %ebp always points to > the frame and is unable to locate function arguments or local variables > when the frame pointer is omitted. The changes allow GDB to locate the > frame based on the value in %esp. > > > Perhaps even a short test case, before and after the change? > > An example is backtracing through sigtramps on Solaris (the Solaris library > contains functions which don't use %ebp as the frame pointer). For example > ... the backtrace from gdb.base/a1-selftest.exp (without my patch) shows: > > #0 0x80068745 in _libc_sigprocmask () > #1 0x80098763 in sigprocmask () > #2 0x8107cb3 in rl_signal_handler (sig=134509072) at signals.c:156 > #3 0x800685b1 in _sigacthandler () > #4 <signal handler called> > #5 0x800682b8 in _libc_read () > #6 0x8101ef9 in rl_getc (stream=0x800a9ad4) at readline.c:3123 > #7 0x80ffa5b in rl_read_key () at readline.c:578 > > The correct backtrace is: > > #0 0x80068745 in _libc_sigprocmask () > #1 0x80098763 in sigprocmask () > #2 0x8107fe7 in rl_signal_handler (sig=134509096) at signals.c:156 > #3 0x800685b1 in _sigacthandler () > #4 <signal handler called> > #5 0x800682b8 in _libc_read () > #6 0x80098b33 in read () > #7 0x810222d in rl_getc (stream=0x81639a0) at readline.c:3123 > #8 0x80ffd8f in rl_read_key () at readline.c:578 > > > Also, do the original problems affect Solaris alone, or are they > > common to all gcc/x86-based architectures? > > They're common to all gcc/x86-based architectures. > > > It's quite difficult to judge a large patch for two different problems > > without having a more-or-less clear notion of the issues involved. > > Actually they're slight variations of same problem which is how to locate > the frame. The GDB patch in question supports locating the frame for x86 > code: > > 1) In a leaf function where the frame pointer has been omitted. GCC > currently supports generating this if -momit-leaf-frame-pointer is > specified. It's desirable to make this the default once debugging > support is in place. > > 2) In a function where the frame pointer has been omitted and the stack > pointer is unchanging. For example: > > int global; > > void > unchanging_sp(int a, int b) > { > > global = a + b; > print_global(); > } > > I have a patch for GCC to support omitting the frame pointer in this > case which has been delayed pending debugger support. It's desirable > to also have this as part of the default x86 code generation strategy. > > 3) In a function where "andl" has been used to align the frame. I have > an experimental patch for GCC to support aligning the frame in this > fashion in order to improve x86 floating point performance. > > The original GDB work was done in November 1998 and January 1999. I'd be > happy to dust things off on my side in order to get these changes installed > if you're interested in working with me. BTW, the necessary paperwork > is already on file. > > -- John > ------------------------------------------------------------------------- > | Feith Systems | Voice: 1-215-646-8000 | Email: john@feith.com | > | John Wehle | Fax: 1-215-540-5495 | | > ------------------------------------------------------------------------- From nsd@cygnus.com Sat Apr 01 00:00:00 2000 From: nsd@cygnus.com To: gdb-patches@sourceware.cygnus.com Subject: RFA: patch to ignore C++ method conversion errors Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003302327.XAA08910@nog.bosbc.com> X-SW-Source: 2000-q1/msg01132.html Content-length: 3043 Hi, When GDB tries to handle a command like "call foo.method()", it walks through foo's methods, calling check_stub_method() on each method until finding one with the correct prototype. check_stub_method() calls parse_and_eval_type(), which calls error() if it encounters any surprises. As a result, "call foo.method()" can fail due to problems with some other method in the same class. For example, if a program containing the following is compiled with STABS info and a non-debugging libstdc++: #include <iostream> class Foo { public: void method1(ostream *); void method2(); } foo; then "ostream" isn't present in the STABS symbol table, which makes "call foo.method2()" fail with the following error: No symbol "ostream" in current context. Here's a simple fix which wraps the parse_and_eval_type() call within catch_errors() and disables error messages during that call. There are no regressions on sparc-sun-solaris2.5.1. It actually seems to fix a pthreads regression; I haven't investigated why. Okay to apply this, Dan? Nick Duffek nsd@cygnus.com [patch follows] Index: gdbtypes.c =================================================================== RCS file: /cvs/src/src/gdb/gdbtypes.c,v retrieving revision 1.6 diff -u -r1.6 gdbtypes.c --- gdbtypes.c 2000/03/28 02:25:14 1.6 +++ gdbtypes.c 2000/03/29 20:00:39 @@ -1422,6 +1422,56 @@ #undef ADD_EXTRA /* End of new code added to support parsing of Cfront stabs strings */ +/* safe_parse_type_stub() args and return val. */ + +struct safe_parse_type_args + { + char *p; + int length; + struct type *type; + }; + +/* catch_errors() stub for safe_parse_type(). */ + +static int +safe_parse_type_stub (void *argsv) +{ + struct safe_parse_type_args *args = (struct safe_parse_type_args *)argsv; + args->type = parse_and_eval_type (args->p, args->length); + return 1; +} + +/* Restore context saved by safe_parse_type. */ + +static void +safe_parse_cleanup (void *gdb_stderrv) +{ + ui_file_delete (gdb_stderr); + gdb_stderr = (struct ui_file *)gdb_stderrv; +} + +/* Parse a type expression in the string [P..P+LENGTH). If an error occurs, + silently return builtin_type_void. */ + +static struct type * +safe_parse_type (char *p, int length) +{ + struct safe_parse_type_args args; + struct cleanup *cleanup; + + args.p = p; + args.length = length; + cleanup = make_cleanup (safe_parse_cleanup, gdb_stderr); + gdb_stderr = ui_file_new (); + + if (!catch_errors (safe_parse_type_stub, &args, "", RETURN_MASK_ERROR)) + args.type = builtin_type_void; + + do_cleanups (cleanup); + + return args.type; +} + /* Ugly hack to convert method stubs into method types. He ain't kiddin'. This demangles the name of the method into a string @@ -1496,7 +1546,7 @@ if (strncmp (argtypetext, "...", p - argtypetext) != 0) { argtypes[argcount] = - parse_and_eval_type (argtypetext, p - argtypetext); + safe_parse_type (argtypetext, p - argtypetext); argcount += 1; } argtypetext = p + 1; From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney <ac131313@cygnus.com> To: Jim Kingdon <kingdon@redhat.com> Cc: gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH] MAINTAINERS - more additions Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38B0E127.1856849A@cygnus.com> References: <38B08387.E542855@cygnus.com> <bd7prqdqf.fsf@rtl.cygnus.com> X-SW-Source: 2000-q1/msg00269.html Content-length: 1103 Jim Kingdon wrote: > > > per an earlier posting, I've committed the following. > > Thanks; I have committed the following (on the theory that a lead > maintainer, in this case for web pages, gets to set policies for that > area): In general no. I'd expect it to be put forward for discussion. However, here I was clearly baiting you and you've fallen for my trap :-) Andrew > 2000-02-21 Jim Kingdon <kingdon@redhat.com> > > * MAINTAINERS (Misc): Clarify that yes, anyone can edit web pages. > > Index: MAINTAINERS > =================================================================== > RCS file: /cvs/src/src/gdb/MAINTAINERS,v > retrieving revision 1.7 > retrieving revision 1.8 > diff -u -r1.7 -r1.8 > --- MAINTAINERS 2000/02/21 00:15:55 1.7 > +++ MAINTAINERS 2000/02/21 06:13:23 1.8 > @@ -101,7 +101,7 @@ > Misc: > > Web pages. Jim Kingdon kingdon@redhat.com > - (but apparently anyone can tweek stuff?) > + (anyone can edit; kingdon is just lead maintainer) > Makefile.in, configure* ALL > > From rearnsha@arm.com Sat Apr 01 00:00:00 2000 From: Richard Earnshaw <rearnsha@arm.com> To: Nick Clifton <nickc@cygnus.com> Cc: rearnsha@arm.com, gdb-patches@sourceware.cygnus.com Subject: Re: Add support for WinCE toolchains Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200002230958.JAA27935@cam-mail2.cambridge.arm.com> References: <200002222350.PAA09035@elmo.cygnus.com> X-SW-Source: 2000-q1/msg00330.html Content-length: 821 > Hi J.T. > > : >>>>> "Nick" == Nick Clifton <nickc@cygnus.com> writes: > : Nick> May I have permission to apply the following patch please ? It adds > : Nick> support for toolchains which are targeted at Microsoft's WinCE > : Nick> execution environment. For the moment this means the sh-pe, mips-pe > : Nick> and arm-wince-pe toolchains. > : > : Perhaps a stupid question, but why are the sh and mips winCE ports > : <arch>-pe, while the arm port is arm-wince-pe? > > Because there is another arm-pe port already in existance which is > incompatible with the WinCE binaries. Thus if you configure with > --target=arm-pe you will get a different toolchain to configuring with > --target=arm-wince-pe. > > Cheers > Nick But surely, the target should be arm-*-wince (in the same way as sparc-*-solaris). R. ^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2000-04-01 0:00 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <200003031956.OAA23859@delysid.gnu.org>
2000-03-20 16:36 ` GDB manual and @smallbook Stan Shebs
2000-04-01 0:00 ` Brian Youmans
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox