From mboxrd@z Thu Jan 1 00:00:00 1970 From: "S. Morningthunder" To: Subject: Forward from GNU volunteer coordination Date: Sun, 31 Oct 1999 10:59:00 -0000 Message-id: X-SW-Source: 1999-q4/msg00120.html This man shows interest in the over-the-ethernet debugger stub. ------- Start of forwarded message ------- Resent-From: GNU Mailing List Maintenance Resent-To: gvc@gnu.org Date: Fri, 22 Oct 1999 22:19:48 -0400 From: mamin To: gnu@gnu.org Subject: Q. about [Kernel-Related Projects] Hi, I am C/C++ developer on various linux platforms. I read abou the following project for FSF: "Kernel-Related Projects An over-the-ethernet debugger stub that will allow the kernel to be debugged from GDB running on another machine. This stub needs its own self-contained implementation of all protocols to be used, since the GNU system will use user processes to implement all but the lowest levels, and the stub won't be able to use those processes. If a simple self-contained implementation of IP and TCP is impractical, it might be necessary to design a new, simple protocol based directly on ethernet. It's not crucial to support high speed or communicating across gateways. It might be possible to use the Mach ethernet driver code, but it would need some changes. " I wish to know what are the current development tasks, how can I join? Thank you in advance, yours, Mohamed Amin ------- End of forwarded message ------- >From cgf@cygnus.com Sun Oct 31 11:00:00 1999 From: cgf@cygnus.com (Chris Faylor) To: gdb-patches@sourceware.cygnus.com Subject: Re: Patch: --enable-profiling Date: Sun, 31 Oct 1999 11:00:00 -0000 Message-id: <7vi2tg$ssf$1@cronkite.cygnus.com> References: <87u2n97vaa.fsf@cygnus.com> <199910300045.RAA15367@andros.cygnus.com> <199910311504.HAA00905@ferrule.cygnus.com> X-SW-Source: 1999-q4/msg00121.html Content-length: 1046 In article < 199910311504.HAA00905@ferrule.cygnus.com >, Tom Tromey wrote: >Stan> BTW, will this work with djgpp and/or cygwin? What will happen >Stan> if you try to configure on those with --enabling-profiling? > >It might work or it might not. I don't know. My theory is that >profiling gdb is a maintainer thing, and if somebody uses >--enable-profiling and it doesn't build, they had better know what >they are doing anyway. We can always add tests for functions later. >I could add them now if it is important; it is easy enough to do. >Ordinarily I'm zealous about portability, but in this case I don't >think it matters that much. DJ Delorie and Stan Cox made some changes to support profiling in Cygwin last year. So, I think that this will probably "work" as in it will compile and link but it probably won't give terribly useful results. Windows didn't provide some of the timing stuff that was crucial for getting accurate information. -chris -- cgf@cygnus.com http://www.cygnus.com/ >From tromey@cygnus.com Sun Oct 31 11:59:00 1999 From: Tom Tromey To: gdb-patches@sourceware.cygnus.com Subject: Patch: Updated --enable-profiling Date: Sun, 31 Oct 1999 11:59:00 -0000 Message-id: <87r9ib70xq.fsf@cygnus.com> X-SW-Source: 1999-q4/msg00122.html Content-length: 7401 Here is an updated version of my --enable-profiling patch. This one includes changes suggested by Stan and Michael. 1999-10-29 Tom Tromey * config.in: Rebuilt. * acconfig.h (ENABLE_PROFILE): New #undef. * Makefile.in (PROFILE_CFLAGS): New macro. * configure: Rebuilt. * configure.in: Added --enable-profiling. Define ENABLE_PROFILE if provided. Set and subst PROFILE_CFLAGS. * maint.c (maint_profile_gdb): New function. (_initialize_maint_cmds): Add `profile-gdb' command if profiling support is enabled. * main.c (main): Turn off profiling if profiling support is enabled. 1999-10-31 Tom Tromey * gdbint.texinfo (Profiling GDB): New node. More comments / requests? Or is this ok to commit? Tom Index: Makefile.in =================================================================== RCS file: /cvs/cvsfiles/devo/gdb/Makefile.in,v retrieving revision 1.662.2.4 diff -u -r1.662.2.4 Makefile.in --- Makefile.in 1999/06/15 17:57:51 1.662.2.4 +++ Makefile.in 1999/10/31 19:51:21 @@ -206,7 +206,7 @@ # M{H,T}_CFLAGS, if defined, have host- and target-dependent CFLAGS # from the config directory. GLOBAL_CFLAGS = $(MT_CFLAGS) $(MH_CFLAGS) -#PROFILE_CFLAGS = -pg +PROFILE_CFLAGS = @PROFILE_CFLAGS@ # CFLAGS is specifically reserved for setting from the command line # when running make. I.E. "make CFLAGS=-Wmissing-prototypes". Index: acconfig.h =================================================================== RCS file: /cvs/cvsfiles/devo/gdb/acconfig.h,v retrieving revision 2.19 diff -u -r2.19 acconfig.h --- acconfig.h 1999/03/24 00:57:12 2.19 +++ acconfig.h 1999/10/31 19:51:23 @@ -96,3 +96,6 @@ /* Set to true if the save_state_t structure has the ss_wide member */ #define HAVE_STRUCT_MEMBER_SS_WIDE 0 + +/* Define if profiling support should be enabled. */ +#undef ENABLE_PROFILE Index: config.in =================================================================== RCS file: /cvs/cvsfiles/devo/gdb/config.in,v retrieving revision 2.34 diff -u -r2.34 config.in --- config.in 1999/03/24 00:57:12 2.34 +++ config.in 1999/10/31 19:51:25 @@ -129,6 +129,9 @@ /* Set to true if the save_state_t structure has the ss_wide member */ #define HAVE_STRUCT_MEMBER_SS_WIDE 0 +/* Define if profiling support should be enabled. */ +#undef ENABLE_PROFILE + /* Define if you have the __argz_count function. */ #undef HAVE___ARGZ_COUNT Index: configure.in =================================================================== RCS file: /cvs/cvsfiles/devo/gdb/configure.in,v retrieving revision 1.385.2.1 diff -u -r1.385.2.1 configure.in --- configure.in 1999/04/15 22:53:46 1.385.2.1 +++ configure.in 1999/10/31 19:51:34 @@ -330,7 +330,16 @@ dnl Handle optional features that can be enabled. ENABLE_CFLAGS= +PROFILE_CFLAGS= +AC_ARG_ENABLE(profiling, +[ --enable-profiling Turn on profiling of gdb]) + +if test "$enable_profiling" = yes; then + AC_DEFINE(ENABLE_PROFILE) + PROFILE_CFLAGS=-pg +fi + AC_ARG_ENABLE(tui, [ --enable-tui Enable full-screen terminal user interface], [ @@ -681,6 +690,7 @@ AC_SUBST(IGNORE_SIM_OBS) AC_SUBST(ENABLE_CFLAGS) +AC_SUBST(PROFILE_CFLAGS) AC_SUBST(CONFIG_OBS) AC_SUBST(CONFIG_DEPS) Index: main.c =================================================================== RCS file: /cvs/cvsfiles/devo/gdb/main.c,v retrieving revision 1.164.2.1 diff -u -r1.164.2.1 main.c --- main.c 1999/04/15 22:53:48 1.164.2.1 +++ main.c 1999/10/31 19:51:41 @@ -128,6 +128,10 @@ int gdb_file_size; +#ifdef ENABLE_PROFILE + moncontrol (0); +#endif + START_PROGRESS (argv[0], 0); #ifdef MPW Index: maint.c =================================================================== RCS file: /cvs/cvsfiles/devo/gdb/maint.c,v retrieving revision 2.27 diff -u -r2.27 maint.c --- maint.c 1999/04/02 23:11:57 2.27 +++ maint.c 1999/10/31 19:51:46 @@ -56,6 +56,11 @@ static void maintenance_print_command PARAMS ((char *, int)); +#ifdef ENABLE_PROFILE +static void maint_profile_gdb PARAMS ((char *, int)); +#endif + + /* Set this to the maximum number of seconds to wait instead of waiting forever in target_wait(). If this timer times out, then it generates an error and the command is aborted. This replaces most of the need for timeouts in the @@ -339,6 +344,26 @@ return; } +/* "maintenance profile-gdb " */ +static void +maint_profile_gdb (char *arg, int from_tty) +{ +#ifdef ENABLE_PROFILE + int val; + if (arg == NULL || ! *arg) + error ("requires argument (\"on\" or \"off\""); + if (! strcmp (arg, "on")) + val = 1; + else if (! strcmp (arg, "off")) + val = 0; + else + error ("unrecognized argument; must be \"on\" or \"off\""); + moncontrol (val); +#else + error ("gdb was not configured with --enable-profiling"); +#endif +} + void _initialize_maint_cmds () { @@ -431,6 +456,12 @@ add_cmd ("translate-address", class_maintenance, maintenance_translate_address, "Translate a section name and address to a symbol.", &maintenancelist); + +#ifdef ENABLE_PROFILE + add_cmd ("profile-gdb", class_maintenance, maint_profile_gdb, + "Enable or disable profiling.", + &maintenancelist); +#endif add_show_from_set ( add_set_cmd ("watchdog", class_maintenance, var_zinteger, (char *)&watchdog, Index: doc/gdbint.texinfo =================================================================== RCS file: /cvs/cvsfiles/devo/gdb/doc/gdbint.texinfo,v retrieving revision 1.110 diff -u -r1.110 gdbint.texinfo --- gdbint.texinfo 1999/04/12 12:32:53 1.110 +++ gdbint.texinfo 1999/10/31 19:52:27 @@ -2522,6 +2522,7 @@ @menu * Getting Started:: Getting started working on GDB * Debugging GDB:: Debugging GDB with itself +* Profiling GDB:: Profiling GDB @end menu @node Getting Started,,, Hints @@ -2728,6 +2729,28 @@ @end table +@node Profiling GDB,,, Hints + +@section Profiling GDB + +GDB contains some support for profiling itself. Currently this support +is rudimentary. + +You can configure GDB with @samp{--enable-profiling}. This does two +things. First, it arranges for GDB to be compiled and linked with +@samp{-pg}. (This might not work on all platforms; feel free to submit +patches to fix this for your platform.) Second, this configure flag +arranges for the @code{maint profile-gdb} command to be enabled. + +@code{maint profile-gdb} takes a single argument, which must be +@samp{on} or @samp{off}. This command enables or disables profiling of +gdb, and can be used to limit profiling to a chosen set of user +commands. + +Note that when configured this way, GDB disables profiling in +@code{main}. If you want to profile GDB's initialization code, you will +have to arrange to build GDB with @code{-pg} but without +@samp{ENABLE_PROFILE} defined. @contents @bye Index: NEWS =================================================================== RCS file: /cvs/cvsfiles/devo/gdb/NEWS,v retrieving revision 2.58 diff -u -r2.58 NEWS --- NEWS 1999/04/13 00:17:35 2.58 +++ NEWS 1999/10/31 19:56:39 @@ -7,6 +7,12 @@ TI TMS320C80 tic80-*-* +* Profiling for gdb + +If gdb is configured with `--enable-profiling', then gdb is built with +`-pg' and a new `maintenance profile-gdb' command is created. This +command can be used to enable or disable profiling, making it possible +to profile a single command or set of commands. *** Changes in GDB-4.18: >From kingdon@redhat.com Sun Oct 31 16:48:00 1999 From: Jim Kingdon To: gdb-patches@sourceware.cygnus.com Cc: robertl@sco.com Subject: [robertl@sco.com: threads RH6/Sparc vs. GDB] Date: Sun, 31 Oct 1999 16:48:00 -0000 Message-id: <199911010048.TAA07679@devserv.devel.redhat.com> X-SW-Source: 1999-q4/msg00123.html Content-length: 4740 The following looks OK to me (well, I haven't looked into the ptrace header lossage stuff but I can tell you we are shipping a similar patch). ------- Start of forwarded message ------- Return-Path: Date: Fri, 29 Oct 1999 17:22:51 -0500 From: Robert Lipe To: kingdon@redhat.com Subject: threads RH6/Sparc vs. GDB Content-Type: text/plain; charset=us-ascii Hi, Jim. I hope everything is going well for you at your new gig. I had a reason to revisit my threaded app on RH6.0/Sparc with GDB. With minor mods to the code in the GDB tree that I flagtrantly (attached) cabbaged from your work, GDB no longer goes completely down in flames. I offer these under the "trivial and obvious" clause in hope that you see a way to stick these someplace so that each Linux port isn't left to fend for thier own. (Since I have only a lowly classic, builds are really painful for me. I suppose I could cross build it from a modern computer, but I don't know that would really be any faster once I got done screwing around with libraries and headers...) . . . I now see the tell-tale [New Thread 18244 (manager thread)] [New Thread 18239 (initial thread)] [New Thread 18245] messages at startup. Stack traces are toast, but things are much more resonable right now. So consider those patches as an improvement. I didn't include a changelog becuase, well, they're your code. :-) . . . Thanx for any help you can offer. RJL Index: infptrace.c =================================================================== RCS file: /cvs/gdb/gdb/gdb/infptrace.c,v retrieving revision 1.1.1.3 diff -u -p -r1.1.1.3 infptrace.c - --- infptrace.c 1999/08/09 21:33:34 1.1.1.3 +++ infptrace.c 1999/10/29 22:10:41 @@ -40,6 +40,10 @@ #include #else #ifdef HAVE_SYS_PTRACE_H +#undef PTRACE_GETREGS +#undef PTRACE_SETREGS +#undef PTRACE_GETFPREGS +#undef PTRACE_SETFPREGS #include #endif #endif Index: sparc-nat.c =================================================================== RCS file: /cvs/gdb/gdb/gdb/sparc-nat.c,v retrieving revision 1.1.1.3 diff -u -p -r1.1.1.3 sparc-nat.c - --- sparc-nat.c 1999/10/05 23:08:51 1.1.1.3 +++ sparc-nat.c 1999/10/29 22:10:43 @@ -24,6 +24,10 @@ #include "gdbcore.h" #include +#undef PTRACE_GETREGS +#undef PTRACE_SETREGS +#undef PTRACE_GETFPREGS +#undef PTRACE_SETFPREGS #include #include #ifdef __linux__ Index: config/sparc/linux.mh =================================================================== RCS file: /cvs/gdb/gdb/gdb/config/sparc/linux.mh,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 linux.mh - --- linux.mh 1999/04/16 01:34:25 1.1.1.1 +++ linux.mh 1999/10/29 22:10:43 @@ -2,6 +2,6 @@ XDEPFILES= ser-tcp.o XM_FILE= xm-linux.h NAT_FILE= nm-linux.h - -NATDEPFILES= fork-child.o infptrace.o inftarg.o corelow.o sparc-nat.o +NATDEPFILES= fork-child.o infptrace.o inftarg.o corelow.o sparc-nat.o linux-thread.o HOST_IPC=-DBSD_IPC GDBSERVER_DEPFILES= low-sparc.o Index: config/sparc/nm-linux.h =================================================================== RCS file: /cvs/gdb/gdb/gdb/config/sparc/nm-linux.h,v retrieving revision 1.1.1.2 diff -u -p -r1.1.1.2 nm-linux.h - --- nm-linux.h 1999/07/07 20:17:01 1.1.1.2 +++ nm-linux.h 1999/10/29 22:10:43 @@ -30,3 +30,22 @@ extern int kernel_u_size PARAMS ((void)) /* Linux is svr4ish but not that much */ #undef USE_PROC_FS + +/* Support for the glibc linuxthreads package. */ + +#ifdef __STDC__ +struct objfile; +#endif + +extern void +linuxthreads_new_objfile PARAMS ((struct objfile *objfile)); +#define target_new_objfile(OBJFILE) linuxthreads_new_objfile (OBJFILE) + +extern char * +linuxthreads_pid_to_str PARAMS ((int pid)); +#define target_pid_to_str(PID) linuxthreads_pid_to_str (PID) + +extern int +linuxthreads_prepare_to_proceed PARAMS ((int step)); +#define PREPARE_TO_PROCEED(select_it) linuxthreads_prepare_to_proceed (1) + Index: config/sparc/tm-linux.h =================================================================== RCS file: /cvs/gdb/gdb/gdb/config/sparc/tm-linux.h,v retrieving revision 1.1.1.2 diff -u -p -r1.1.1.2 tm-linux.h - --- tm-linux.h 1999/07/07 20:17:06 1.1.1.2 +++ tm-linux.h 1999/10/29 22:10:43 @@ -21,6 +21,19 @@ #ifndef TM_SPARCLINUX_H #define TM_SPARCLINUX_H +/* Some versions of Linux have real-time signal support in the C library, and + some don't. We have to include this file to find out. */ +#include + +#ifdef __SIGRTMIN +#define REALTIME_LO __SIGRTMIN +#define REALTIME_HI (__SIGRTMAX + 1) +#else +#define REALTIME_LO 32 +#define REALTIME_HI 64 +#endif + + #include "sparc/tm-sparc.h" #define SIGCONTEXT_PC_OFFSET 12 ------- End of forwarded message ------- >From jimb@cygnus.com Mon Nov 01 07:17:00 1999 From: Jim Blandy To: muller@cerbere.u-strasbg.fr Cc: Michael Snyder , gdb-patches@sourceware.cygnus.com Subject: Re: print_symbol_info patch for source code not current language Date: Mon, 01 Nov 1999 07:17:00 -0000 Message-id: References: <381824BF.BCE63370@cygnus.com> <5mogdjbkr2.fsf@jtc.redbacknetworks.com> <199910291101.NAA00678@cerbere.u-strasbg.fr> <3.0.6.32.19991029232856.0089fdc0@ics.u-strasbg.fr> X-SW-Source: 1999-q4/msg00124.html Content-length: 687 > >> However, saving, setting, and restoring the current language is > >> somewhat messy. Note that the definition of type_print just calls > >> LA_PRINT_TYPE, which calls current_language->la_print_type. Your code > >> could simply determine the appropriate language, L, and then call > >> L->la_print_type directly, instead of print_type. > > > >Sounds like a good idea. > > That was my first try but its not a good solution because then you > get the args output in current_language different from the function > layout itself !!! I'm sorry, I don't understand what you mean. Could you show me an example? (A fake example is okay; I just want to see what you're talking about.) >From jimb@cygnus.com Mon Nov 01 07:25:00 1999 From: Jim Blandy To: Jim Kingdon Cc: gdb-patches@sourceware.cygnus.com, robertl@sco.com Subject: Re: [robertl@sco.com: threads RH6/Sparc vs. GDB] Date: Mon, 01 Nov 1999 07:25:00 -0000 Message-id: References: <199911010048.TAA07679@devserv.devel.redhat.com> X-SW-Source: 1999-q4/msg00125.html Content-length: 1079 What are these changes for? > Index: infptrace.c > =================================================================== > RCS file: /cvs/gdb/gdb/gdb/infptrace.c,v > retrieving revision 1.1.1.3 > diff -u -p -r1.1.1.3 infptrace.c > - --- infptrace.c 1999/08/09 21:33:34 1.1.1.3 > +++ infptrace.c 1999/10/29 22:10:41 > @@ -40,6 +40,10 @@ > #include > #else > #ifdef HAVE_SYS_PTRACE_H > +#undef PTRACE_GETREGS > +#undef PTRACE_SETREGS > +#undef PTRACE_GETFPREGS > +#undef PTRACE_SETFPREGS > #include > #endif > #endif > Index: sparc-nat.c > =================================================================== > RCS file: /cvs/gdb/gdb/gdb/sparc-nat.c,v > retrieving revision 1.1.1.3 > diff -u -p -r1.1.1.3 sparc-nat.c > - --- sparc-nat.c 1999/10/05 23:08:51 1.1.1.3 > +++ sparc-nat.c 1999/10/29 22:10:43 > @@ -24,6 +24,10 @@ > #include "gdbcore.h" > > #include > +#undef PTRACE_GETREGS > +#undef PTRACE_SETREGS > +#undef PTRACE_GETFPREGS > +#undef PTRACE_SETFPREGS > #include > #include > #ifdef __linux__ >From hjl@lucon.org Mon Nov 01 08:14:00 1999 From: hjl@lucon.org (H.J. Lu) To: kingdon@redhat.com (Jim Kingdon) Cc: gdb-patches@sourceware.cygnus.com, robertl@sco.com Subject: Re: [robertl@sco.com: threads RH6/Sparc vs. GDB] Date: Mon, 01 Nov 1999 08:14:00 -0000 Message-id: <19991101161449.373C51B493@ocean.lucon.org> References: <199911010048.TAA07679@devserv.devel.redhat.com> X-SW-Source: 1999-q4/msg00126.html Content-length: 413 > > The following looks OK to me (well, I haven't looked into the ptrace > header lossage stuff but I can tell you we are shipping a similar > patch). > May I suggest to hold any Linuxthreads patches for the time being? I have a patch which will make most of them obsolete. I will send a patch after the i387 issue is resolved. I don't want to add more to the backlog of Linux related patches. Thanks. H.J. >From jimb@cygnus.com Mon Nov 01 08:18:00 1999 From: Jim Blandy To: Jimmy Guo Cc: gdb-patches@sourceware.cygnus.com Subject: Re: (patch) hpjyg03: (buildsym|language).[ch] Date: Mon, 01 Nov 1999 08:18:00 -0000 Message-id: References: X-SW-Source: 1999-q4/msg00127.html Content-length: 2063 Thanks! I have some questions, though: > + 1999-10-29 Jimmy Guo > + > + * buildsym.h (free_pendings): Declare. > + > + * buildsym.c: Make free_pendings global, and misc. fixes. > + (make_blockvector): 32x64 fix using longest_local_hex_string(). > + (start_subfile): initialize variable 'subfile'. > + (end_symtab): fix bug freeing 'subfiles' list element, when it's > + the list head to be freed. ... > *** gdb/buildsym.h > --- gdb/buildsym.h Thu Oct 28 18:11:31 1999 > *************** > *** 109,114 **** > --- 109,118 ---- > struct symbol *symbol[PENDINGSIZE]; > }; > > + /* List of free `struct pending' structures for reuse. */ > + > + EXTERN struct pending *free_pendings; > + > /* Here are the three lists that symbols are put on. */ > > /* static at top level, and types */ What are you planning to do with free_pendings elsewhere in GDB? If you make a variable externally visible, that opens it up for arbitrary use anywhere else in GDB. People will see that extern declaration and figure it's okay to do whatever they please. Depending on what the other code needs to do, it might be better instead to export a function from buildsym.c that does one specific operation on free_pendings. That way, it's easier for someone reading buildsym.c to see what kind of interactions to expect from outside. > *************** > *** 998,1003 **** > --- 991,998 ---- > } > > nextsub = subfile->next; > + if (subfiles == subfile) > + subfiles = nextsub; > free ((void *) subfile); > } > Could you explain this change a little more? I understand that the list of subfiles is being freed here, so without this, subfiles ends up being a dangling pointer. But it looks to me like the loop frees the entire list of subfiles. So subfiles will always end up being zero. And it doesn't look to me like subfiles is ever used while the loop is running. So, who is attempting to use subfiles after calling end_symtab without calling start_symtab first to reinitialize things? >From robertl@sco.com Mon Nov 01 09:06:00 1999 From: Robert Lipe To: Jim Blandy Cc: Jim Kingdon , gdb-patches@sourceware.cygnus.com Subject: Re: [robertl@sco.com: threads RH6/Sparc vs. GDB] Date: Mon, 01 Nov 1999 09:06:00 -0000 Message-id: <19991101110509.O19769@rjlhome.sco.com> References: <199911010048.TAA07679@devserv.devel.redhat.com> X-SW-Source: 1999-q4/msg00128.html Content-length: 1604 Jim Blandy wrote: > What are these changes for? These are unrelated to the Sparc/threads issue and were, in fact, included quite by mistake. :-) I know this is absolutely the wrong way to "fix" this problem, but if the moral equivalent of this isn't done, RH6 on Sparc will not build GDB becuase it gets all tangled up in the code that redefines PTRACE_*REGS code. >From what I recall, sys/ptrace.h and one of the GDB headers were each trying to outsmart the other. RJL > > > Index: infptrace.c > > =================================================================== > > RCS file: /cvs/gdb/gdb/gdb/infptrace.c,v > > retrieving revision 1.1.1.3 > > diff -u -p -r1.1.1.3 infptrace.c > > - --- infptrace.c 1999/08/09 21:33:34 1.1.1.3 > > +++ infptrace.c 1999/10/29 22:10:41 > > @@ -40,6 +40,10 @@ > > #include > > #else > > #ifdef HAVE_SYS_PTRACE_H > > +#undef PTRACE_GETREGS > > +#undef PTRACE_SETREGS > > +#undef PTRACE_GETFPREGS > > +#undef PTRACE_SETFPREGS > > #include > > #endif > > #endif > > Index: sparc-nat.c > > =================================================================== > > RCS file: /cvs/gdb/gdb/gdb/sparc-nat.c,v > > retrieving revision 1.1.1.3 > > diff -u -p -r1.1.1.3 sparc-nat.c > > - --- sparc-nat.c 1999/10/05 23:08:51 1.1.1.3 > > +++ sparc-nat.c 1999/10/29 22:10:43 > > @@ -24,6 +24,10 @@ > > #include "gdbcore.h" > > > > #include > > +#undef PTRACE_GETREGS > > +#undef PTRACE_SETREGS > > +#undef PTRACE_GETFPREGS > > +#undef PTRACE_SETFPREGS > > #include > > #include > > #ifdef __linux__ >From robertl@sco.com Mon Nov 01 09:13:00 1999 From: Robert Lipe To: "H.J. Lu" Cc: Jim Kingdon , gdb-patches@sourceware.cygnus.com Subject: Re: [robertl@sco.com: threads RH6/Sparc vs. GDB] Date: Mon, 01 Nov 1999 09:13:00 -0000 Message-id: <19991101111145.P19769@rjlhome.sco.com> References: <199911010048.TAA07679@devserv.devel.redhat.com> <19991101161449.373C51B493@ocean.lucon.org> X-SW-Source: 1999-q4/msg00129.html Content-length: 718 H.J. Lu wrote: > May I suggest to hold any Linuxthreads patches for the time being? Fine with me. I'm certainly not in a position to argue strongly for them. > I have a patch which will make most of them obsolete. I will send > a patch after the i387 issue is resolved. I don't want to add more > to the backlog of Linux related patches. I would very much like to see something settle down that would benefit the users of GDB and threads on non-IA32 systems as well. I'm sure that the needs of the many (Linux/IA32) outweigh the needs of the few (Linux/everything else) but if this could be worked out in a Linux-dependent manner instead of a Linux/IA32-dependent manner, that would be most helpful. Thanx, RJL >From hjl@lucon.org Mon Nov 01 09:19:00 1999 From: hjl@lucon.org (H.J. Lu) To: robertl@sco.com (Robert Lipe) Cc: hjl@lucon.org (H.J. Lu), kingdon@redhat.com (Jim Kingdon), gdb-patches@sourceware.cygnus.com Subject: Re: [robertl@sco.com: threads RH6/Sparc vs. GDB] Date: Mon, 01 Nov 1999 09:19:00 -0000 Message-id: <19991101171955.2EFD11B493@ocean.lucon.org> References: <19991101111145.P19769@rjlhome.sco.com> X-SW-Source: 1999-q4/msg00130.html Content-length: 718 > > I would very much like to see something settle down that would benefit > the users of GDB and threads on non-IA32 systems as well. I'm sure > that the needs of the many (Linux/IA32) outweigh the needs of the > few (Linux/everything else) but if this could be worked out in a > Linux-dependent manner instead of a Linux/IA32-dependent manner, that > would be most helpful. > My next Linuxthreads patch will make it arch-independent. That is how gdb 4.17.0.14 works on ia32, alpha and ppc. I only needed to modify less than 10 lines to make Linuxthreads work on alpha and ppc. It is very trivial. My guess is Jim used an older gdb 4.17.0.xx for the Linuxthreads support in gdb 4.19. -- H.J. Lu (hjl@gnu.org) >From kingdon@redhat.com Mon Nov 01 09:42:00 1999 From: Jim Kingdon To: robertl@sco.com Cc: davem@redhat.com, jakub@redhat.com Subject: Re: [robertl@sco.com: threads RH6/Sparc vs. GDB] Date: Mon, 01 Nov 1999 09:42:00 -0000 Message-id: <199911011742.MAA28800@devserv.devel.redhat.com> References: <199911010048.TAA07679@devserv.devel.redhat.com> <19991101110509.O19769@rjlhome.sco.com> X-SW-Source: 1999-q4/msg00131.html Content-length: 1694 > From what I recall, sys/ptrace.h and one of the GDB headers were each > trying to outsmart the other. No, it is two system headers. /usr/include/asm-sparc/ptrace.h (included via a dizzying cascade of includes from /usr/include/signal.h) and /usr/include/sys/ptrace.h. The former contains "#define PTRACE_GETREGS 12" and the latter has an enum which contains "PTRACE_GETREGS = 12". DaveM, Jakub, let's get this fixed. We've been kludging around it in GDB long enough. (Something along these lines is also gdb-4.18-sparcmin.patch in any recent Red Hat RPM for GDB) > > Index: infptrace.c > > =================================================================== > > RCS file: /cvs/gdb/gdb/gdb/infptrace.c,v > > retrieving revision 1.1.1.3 > > diff -u -p -r1.1.1.3 infptrace.c > > - --- infptrace.c 1999/08/09 21:33:34 1.1.1.3 > > +++ infptrace.c 1999/10/29 22:10:41 > > @@ -40,6 +40,10 @@ > > #include > > #else > > #ifdef HAVE_SYS_PTRACE_H > > +#undef PTRACE_GETREGS > > +#undef PTRACE_SETREGS > > +#undef PTRACE_GETFPREGS > > +#undef PTRACE_SETFPREGS > > #include > > #endif > > #endif > > Index: sparc-nat.c > > =================================================================== > > RCS file: /cvs/gdb/gdb/gdb/sparc-nat.c,v > > retrieving revision 1.1.1.3 > > diff -u -p -r1.1.1.3 sparc-nat.c > > - --- sparc-nat.c 1999/10/05 23:08:51 1.1.1.3 > > +++ sparc-nat.c 1999/10/29 22:10:43 > > @@ -24,6 +24,10 @@ > > #include "gdbcore.h" > > > > #include > > +#undef PTRACE_GETREGS > > +#undef PTRACE_SETREGS > > +#undef PTRACE_GETFPREGS > > +#undef PTRACE_SETFPREGS > > #include > > #include > > #ifdef __linux__ >From kingdon@redhat.com Mon Nov 01 10:07:00 1999 From: Jim Kingdon To: hjl@lucon.org Cc: gdb-patches@sourceware.cygnus.com, robertl@sco.com Subject: Re: [robertl@sco.com: threads RH6/Sparc vs. GDB] Date: Mon, 01 Nov 1999 10:07:00 -0000 Message-id: <199911011806.NAA29518@devserv.devel.redhat.com> References: <19991101161449.373C51B493@ocean.lucon.org> X-SW-Source: 1999-q4/msg00132.html Content-length: 810 > May I suggest to hold any Linuxthreads patches for the time being? > I have a patch which will make most of them obsolete. I will send > a patch after the i387 issue is resolved. I don't want to add more > to the backlog of Linux related patches. I don't see any reason why threads should need to wait until after 387. A patch in the hand is worth two in the bush (Cygnus also has quite a few threads patches/rewrites in the bush, which sound good from what I've heard, but I'm not putting off all thread work until they show up). If people want to make the threads configuration stuff arch-independent (which I agree is the clean solution), that's OK. But if no patch to do so is forthcoming, I'd vote for checking in robertl's sparc patch (minus the ptrace header kludges) until this can be done right. >From robertl@sco.com Mon Nov 01 10:10:00 1999 From: Robert Lipe To: Jim Kingdon Cc: jimb@cygnus.com, gdb-patches@sourceware.cygnus.com, davem@redhat.com, jakub@redhat.com Subject: Re: [robertl@sco.com: threads RH6/Sparc vs. GDB] Date: Mon, 01 Nov 1999 10:10:00 -0000 Message-id: <19991101120917.S19769@rjlhome.sco.com> References: <199911010048.TAA07679@devserv.devel.redhat.com> <19991101110509.O19769@rjlhome.sco.com> <199911011742.MAA28800@devserv.devel.redhat.com> X-SW-Source: 1999-q4/msg00133.html Content-length: 617 > > From what I recall, sys/ptrace.h and one of the GDB headers were > > each trying to outsmart the other. > > No, it is two system headers. /usr/include/asm-sparc/ptrace.h > (included via a dizzying cascade of includes from > /usr/include/signal.h) and /usr/include/sys/ptrace.h. The former > contains "#define PTRACE_GETREGS 12" and the latter has an enum which > contains "PTRACE_GETREGS = 12". Yes, that does definitely sound familar now that you mention it. This has been in my local tree for several months, so I had forgotten the details. Only by looking at the cpp output does it become "obvious". RJL >From guo@cup.hp.com Mon Nov 01 10:26:00 1999 From: Jimmy Guo To: Jim Blandy Cc: gdb-patches@sourceware.cygnus.com Subject: Re: (patch) hpjyg03: (buildsym|language).[ch] Date: Mon, 01 Nov 1999 10:26:00 -0000 Message-id: References: X-SW-Source: 1999-q4/msg00134.html Content-length: 2408 >What are you planning to do with free_pendings elsewhere in GDB? > >If you make a variable externally visible, that opens it up for >arbitrary use anywhere else in GDB. People will see that extern >declaration and figure it's okay to do whatever they please. > >Depending on what the other code needs to do, it might be better >instead to export a function from buildsym.c that does one specific >operation on free_pendings. That way, it's easier for someone reading >buildsym.c to see what kind of interactions to expect from outside. The other code (hp-symtab-read.c (hpread_read_function_type)) uses a 'local_list' to add fparam to. If the routine is called just to get the function type (instead of for creating a new block), this local_list does not get 'freed', but should be. Looking at the code again I agree that the free_pendings list should probably stay local and let a specific function to manage additions to the list. I will revise the patch to reflect your input! >> nextsub = subfile->next; >> + if (subfiles == subfile) >> + subfiles = nextsub; >> free ((void *) subfile); >> } >> > >Could you explain this change a little more? I understand that the >list of subfiles is being freed here, so without this, subfiles ends >up being a dangling pointer. But it looks to me like the loop frees >the entire list of subfiles. So subfiles will always end up being >zero. And it doesn't look to me like subfiles is ever used while the >loop is running. > >So, who is attempting to use subfiles after calling end_symtab without >calling start_symtab first to reinitialize things? Good question. The fix was related to a HP-UX 11.0 test failure about a year ago, related to HP aCC support. Since 1) the test involved is no longer available (duh) 2) there are tons of failures right now with Cygnus GDB when it comes to HP aCC support, I'm going to postpone merging this particular piece of code until we are at a stage where I can be better positioned to triage a failure that could be related to this to provide a real answer :) For now, I think this change is nice to have (although I'd just put in a 'subfiles = NULL' after the loop instead), but could shadow a real problem / issue somewhere else where subfiles is referenced after end_symtab(). Stay tuned for a revision of the patch. Thanks for the comments, Jim! - Jimmy Guo, guo@cup.hp.com