From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Kettenis To: hjl@valinux.com Cc: gdb-patches@sourceware.cygnus.com, gdb@sourceware.cygnus.com Subject: Re: A revised patch for dlclose Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003080058.e280wga00453@delius.kettenis.local> References: <20000307120800.A27315@valinux.com> X-SW-Source: 2000-q1/msg00572.html Date: Tue, 7 Mar 2000 12:08:00 -0800 From: "H . J . Lu" Here is a revised patch for dlclose. If you take a look at the dynamic linker in glibc 2.1 or above, you will find that it informs gdb about loading/unloading a shared library via an internal debug function, _dl_debug_state (). gdb already handles the loading in handle_inferior_event () with BPSTAT_WHAT_CHECK_SHLIBS and BPSTAT_WHAT_CHECK_SHLIBS_RESUME_FROM_HOOK. However, we need also check the unloading event. solib_verify () will be called only when the dynamic linker calls _dl_debug_state (). It shouldn't introduce any overhead. I believe it is on the right track although it may be further optimized. HJ, please stop wasting your time pushing this patch. The patch has several bad points, that you cannot fix without considerable changes to the way solib.c handles and caches the link map. Mark >From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: Jason Molenda Cc: "J.T. Conklin" , gdb-patches@sourceware.cygnus.com Subject: Re: patch: convert gdbserver to autoconf, add netbsd/i386 support Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38A4FA26.B8C19E9A@cygnus.com> References: <5mn1p88ma8.fsf@jtc.redbacknetworks.com> <20000210192010.A12329@cygnus.com> X-SW-Source: 2000-q1/msg00131.html Content-length: 723 Jason Molenda wrote: > > After a brief visual inspection the configury changes look good to me. > (not that my opinion is the one that counts :-) > > On Thu, Feb 10, 2000 at 07:12:47PM -0800, J.T. Conklin wrote: > > > I used autoconf 2.12 to generate the gdbserver/configure script. If > > there's a more official version, feel free to re-generate it. > > Submitting auto-generated files like this really isn't necessary > (it just makes a patch look a whole lot longer than it really is). > FWIW autoconf 2.13 is the latest released version; it's the one that > should be used to generate any configure files. > > Thanks for the patch, it's one less use of the old Cygnus configure cruft. Its fine with me. Andrew >From jtc@redback.com Sat Apr 01 00:00:00 2000 From: jtc@redback.com (J.T. Conklin) To: Andrew Cagney Cc: gdb-patches@sourceware.cygnus.com Subject: Re: RFA: USE_STRUCT_CONVENTION for NetBSD/i386 Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <5md7okvwfx.fsf@jtc.redbacknetworks.com> References: <5msnxieegg.fsf@jtc.redbacknetworks.com> <38DAD990.D91D6D1B@cygnus.com> X-SW-Source: 2000-q1/msg01005.html Content-length: 1360 >>>>> "Andrew" == Andrew Cagney writes: >> ! int >> ! i386nbsd_use_struct_convention (int gcc_p, struct type *type) >> ! { >> ! return !(TYPE_LENGTH (type) == 1 >> ! || TYPE_LENGTH (type) == 2 >> ! || TYPE_LENGTH (type) == 4 >> ! || TYPE_LENGTH (type) == 8); >> ! } >> ! Andrew> I'd add a FIXME pointing out known problems with the function. Andrew> Otherwize ok. It's not i386nbsd_use_struct_convention() that needs a FIXME, as it now properly identifies all functions which return structures via a hidden pointer vs. those which return structures via registers. It's i386_extract_return_type() which doesn't know that structures with a single float or double field are returned in floating point registers. Andrew> I assume Mark is trying to figure out why NetBSD can't simply Andrew> use a common i386_use_struct_convention function. I take it Andrew> from your answer, that NetBSD's convention isn't 100% standard Andrew> (where standard would mean what someone other than Linux or Andrew> *BSD did. Solaris/x86?). I don't think NetBSD does anything non-standard other than defining DEFAULT_PCC_STRUCT_RETURN to 0 in its gcc config. So this behavior should be shared among all x86 targets that do the same: cygwin, freebsd, linux-aout, and mach. --jtc -- J.T. Conklin RedBack Networks >From kingdon@redhat.com Sat Apr 01 00:00:00 2000 From: Jim Kingdon To: gdb-patches@sourceware.cygnus.com Subject: "make TAGS" work again after gdbtk reorg Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200002100240.VAA26815@devserv.devel.redhat.com> X-SW-Source: 2000-q1/msg00105.html Content-length: 1186 I needed the following to get "make TAGS" to work (without the change, it would abort with an error; I don't have gdbtk checked out in case that is relevant). 2000-02-09 Jim Kingdon * Makefile.in (SFILES): Remove gdbtk-varobj.c. Index: Makefile.in =================================================================== RCS file: /cvs/src/src/gdb/Makefile.in,v retrieving revision 1.3 diff -u -r1.3 Makefile.in --- Makefile.in 2000/02/09 08:52:44 1.3 +++ Makefile.in 2000/02/10 00:15:28 @@ -419,6 +419,7 @@ # Links made at configuration time should not be specified here, since # SFILES is used in building the distribution archive. +# FIXME: does gdbtk-varobj.c belong here? SFILES = ax-general.c ax-gdb.c bcache.c blockframe.c breakpoint.c \ buildsym.c c-exp.y c-lang.c c-typeprint.c c-valprint.c \ ch-exp.c ch-lang.c ch-typeprint.c ch-valprint.c coffread.c \ @@ -431,7 +432,6 @@ 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 \ >From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: Mark Kettenis Cc: eliz@delorie.com, gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH] Some compiler warnings removed Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38B5F997.EB6593F0@cygnus.com> References: <200002232235.RAA18817@indy.delorie.com> <38B47B3A.24D778B2@cygnus.com> <200002241107.GAA19384@indy.delorie.com> <200002241133.MAA02461@landau.wins.uva.nl> X-SW-Source: 2000-q1/msg00366.html Content-length: 1440 Mark Kettenis wrote: > > Date: Thu, 24 Feb 2000 06:07:57 -0500 (EST) > From: Eli Zaretskii > > > From: Andrew Cagney > > > > > --- gdb/blockframe.c~0 Wed Dec 22 21:45:02 1999 > > > +++ gdb/blockframe.c Wed Feb 23 16:51:44 2000 > > > @@ -70,6 +70,7 @@ nonnull_frame_chain_valid (chain, thisfr > > > CORE_ADDR chain; > > > struct frame_info *thisframe; > > > { > > > + thisframe = thisframe; > > > return ((chain) != 0); > > > } > > > > > > > FWIW, > > > > The way GCC handles this is by appending ATTRIBUTE_UNUSED to the > > parameter declaratons. I see no reason for doing it differently. > > I'm not sure I follow. I know about __attribute__((unused)), but I > thought I couldn't use GCC-specific extensions, except in places which > will never be compiled by anything but GCC (like go32-nat.c). If > there is a portable way of doing this that I missed, please tell me > where to look. > > Take a look at include/ansidecl.h. People who are not using GCC will > have to learn to live with the warnings :-). Just an asside. I personally wish that a few of the GCC -W* flags were tweeked so that they better differentiated between various warnings. Unused locals vs unused parameters is one example. The random warnings from -W is another. Adding ATTRIBUTE_UNUSED is just a compromise. Andrew >From eliz@delorie.com Sat Apr 01 00:00:00 2000 From: Eli Zaretskii To: ac131313@cygnus.com Cc: gdb-patches@sourceware.cygnus.com Subject: Re: [PATCH] Some compiler warnings removed Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200002241107.GAA19384@indy.delorie.com> References: <200002232235.RAA18817@indy.delorie.com> <38B47B3A.24D778B2@cygnus.com> X-SW-Source: 2000-q1/msg00356.html Content-length: 1714 > From: Andrew Cagney > > > --- gdb/blockframe.c~0 Wed Dec 22 21:45:02 1999 > > +++ gdb/blockframe.c Wed Feb 23 16:51:44 2000 > > @@ -70,6 +70,7 @@ nonnull_frame_chain_valid (chain, thisfr > > CORE_ADDR chain; > > struct frame_info *thisframe; > > { > > + thisframe = thisframe; > > return ((chain) != 0); > > } > > > > FWIW, > > The way GCC handles this is by appending ATTRIBUTE_UNUSED to the > parameter declaratons. I see no reason for doing it differently. I'm not sure I follow. I know about __attribute__((unused)), but I thought I couldn't use GCC-specific extensions, except in places which will never be compiled by anything but GCC (like go32-nat.c). If there is a portable way of doing this that I missed, please tell me where to look. > > { > > - /* On AIX and i386 GNU/Linux, floating point values are returned in > > - floating point registers. */ > > -#if defined(I386_AIX_TARGET) || defined(I386_GNULINUX_TARGET) > > + /* On AIX, i386 GNU/Linux and DJGPP, floating point values are > > + returned in floating point registers. */ > > +#if defined(I386_AIX_TARGET) || defined(I386_GNULINUX_TARGET) || defined(I386_DJGPP_TARGET) > > if (TYPE_CODE_FLT == TYPE_CODE (type)) > > { > > double d; > > @@ -720,7 +720,7 @@ i386_extract_return_value (type, regbuf, > > store_floating (valbuf, TYPE_LENGTH (type), d); > > } > > else > > -#endif /* I386_AIX_TARGET || I386_GNULINUX_TARGET*/ > > +#endif /* I386_AIX_TARGET || I386_GNULINUX_TARGET || I386_DJGPP_TARGET */ > > This one looks more like an actual code change? Yes. Sorry, this was intended to be sent with the other batch of changes I sent yesterday. >From taylor@cygnus.com Sat Apr 01 00:00:00 2000 From: David Taylor To: Fernando Nasser Cc: gdb-patches@sourceware.cygnus.com Subject: Re: set rewindonsignal Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200002112015.PAA04866@texas.cygnus.com> X-SW-Source: 2000-q1/msg00127.html Content-length: 2022 Date: Thu, 10 Feb 2000 14:16:36 -0500 From: Fernando Nasser We have two groups of users who want different behavior of gdb when a signal is received as a consequence of a "call somefunction()" command. One wants gdb to return to the state it was before and the other wants gdb to stay in the stack frame where the signal was received, as this can be used to debug some situations (note that, depending on the OS and the context, this can result in a state where execution is not possible anymore). The way to get everyone happy is to add a "set rewindonsignal" which, if "on", will cause the stack to be rewound and the context fully restored when a signal happens on the inferior call. It does not affect breakpoints, which do stop in the frame where they occurred (even if inner than a dummy frame). The default will be "off", as the original gdb behavior was to stop inside the frame. I have changed this temporarily in the snapshots due to a few bugs that we are working on, but as the switch will be available for those affected (they can add it to their .gdbinit files), I will revert in time for the next release. If you think this may have any impact on your work please let me know (but remember you can set the switch anyway you want). To me, rewind is something you do to a file or something similar; and if not otherwise specified, you are rewinding back to the beginning. When I speak of removing stack frames, I generally speak of unwinding the stack. If I didn't know that rewindonsignal unwound the stack back to what it was before the function was called, I wouldn't expect it to do so. So, I would prefer that you use some other name for it as I feel that 'rewindonsignal' doesn't imply what it does. Of course, I'm also in the "leave the stack bloody alone, thank you" camp. The "if I want the stack unwound, I know how to use the return command" camp. So, I will likely never set it. >From Peter.Schauer@regent.e-technik.tu-muenchen.de Sat Apr 01 00:00:00 2000 From: "Peter.Schauer" To: gdb-patches@sourceware.cygnus.com Subject: RFD: infrun.c: No bpstat_stop_status call after proceed over break ? Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003130948.KAA07547@reisser.regent.e-technik.tu-muenchen.de> X-SW-Source: 2000-q1/msg00665.html Content-length: 4730 I am currently trying to fix a GDB bug with missing watchpoint triggers after proceeding over a breakpoint on x86 targets. Here is an example, using gdb.c++/annota2: (gdb) b main Breakpoint 1 at 0x8048b3a: file annota2.cc, line 21. (gdb) r Starting program: annota2 Breakpoint 1, main () at annota2.cc:21 21 a.x = 0; (gdb) watch a.x Watchpoint 2: a.x (gdb) c Continuing. Watchpoint 2: a.x Old value = -536882292 New value = 1 main () at annota2.cc:23 23 a.y = 2; (gdb) The breakpoint at main is at the instruction which should cause the watchpoint trigger (a.x = 0). When continuing over the breakpoint, breakpoints are removed and the target is single stepped with trap_expected set to one. After the step GDB does not reexamine the stop reason, missing the watchpoint trigger at a.x = 0 and stops too late at the second watchpoint trigger. Here is the relevant code from handle_inferior_event: /* Don't even think about breakpoints if just proceeded over a breakpoint. However, if we are trying to proceed over a breakpoint and end up in sigtramp, then through_sigtramp_breakpoint will be set and we should check whether we've hit the step breakpoint. */ if (stop_signal == TARGET_SIGNAL_TRAP && trap_expected && through_sigtramp_breakpoint == NULL) bpstat_clear (&stop_bpstat); else { /* See if there is a breakpoint at the current PC. */ stop_bpstat = bpstat_stop_status (&stop_pc, . . I currently have no idea why we need to special case the proceed over a breakpoint here, perhaps it is some historic remnant (although I do have this nagging feeling that I might miss something obvious). The patch below would get rid of the special case and fix the problem, it causes no testsuite regressions. Note that bpstat_clear is called and stop_print_frame is set to 1 unconditionally already a few lines above the bpstat_stop_status call, so there is no need to do it again. Any suggestions why we should need the old special case ? 2000-03-12 Peter Schauer * infrun.c (handle_inferior_event): Remove special case for stop after proceeding over a breakpoint, it caused missed watchpoints. *** gdb/infrun.c.orig Thu Feb 24 13:41:46 2000 --- gdb/infrun.c Mon Mar 13 10:11:50 2000 *************** *** 2076,2110 **** return; } ! /* Don't even think about breakpoints ! if just proceeded over a breakpoint. ! ! However, if we are trying to proceed over a breakpoint ! and end up in sigtramp, then through_sigtramp_breakpoint ! will be set and we should check whether we've hit the ! step breakpoint. */ ! if (stop_signal == TARGET_SIGNAL_TRAP && trap_expected ! && through_sigtramp_breakpoint == NULL) ! bpstat_clear (&stop_bpstat); ! else ! { ! /* See if there is a breakpoint at the current PC. */ ! stop_bpstat = bpstat_stop_status ! (&stop_pc, ! /* Pass TRUE if our reason for stopping is something other ! than hitting a breakpoint. We do this by checking that ! 1) stepping is going on and 2) we didn't hit a breakpoint ! in a signal handler without an intervening stop in ! sigtramp, which is detected by a new stack pointer value ! below any usual function calling stack adjustments. */ ! (currently_stepping (ecs) ! && !(step_range_end ! && INNER_THAN (read_sp (), (step_sp - 16)))) ! ); ! /* Following in case break condition called a ! function. */ ! stop_print_frame = 1; ! } if (stop_signal == TARGET_SIGNAL_TRAP) ecs->random_signal --- 2092,2114 ---- return; } ! /* See if there is a breakpoint at the current PC. ! Older versions of GDB did not call bpstat_stop_status after ! proceeding over a breakpoint, causing missed watchpoints when ! proceeding over a breakpoint on an instruction which triggers ! a watchpoint. */ ! stop_bpstat = bpstat_stop_status ! (&stop_pc, ! /* Pass TRUE if our reason for stopping is something other ! than hitting a breakpoint. We do this by checking that ! 1) stepping is going on and 2) we didn't hit a breakpoint ! in a signal handler without an intervening stop in ! sigtramp, which is detected by a new stack pointer value ! below any usual function calling stack adjustments. */ ! (currently_stepping (ecs) ! && !(step_range_end ! && INNER_THAN (read_sp (), (step_sp - 16)))) ! ); if (stop_signal == TARGET_SIGNAL_TRAP) ecs->random_signal -- Peter Schauer pes@regent.e-technik.tu-muenchen.de >From paire@ri.silicomp.fr Sat Apr 01 00:00:00 2000 From: Eric Paire To: Kevin Buettner Cc: Jim Blandy , gdb-patches@sourceware.cygnus.com, Michael Snyder Subject: Re: RFA: linux-thread.c change (fixes hang on startup) Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200001241439.PAA24508@mailhost.ri.silicomp.fr> References: <1000122102749.ZM17407@ocotillo.lan> X-SW-Source: 2000-q1/msg00029.html Content-length: 2526 > The code in question looks like this: > > /* initialize SIGCHLD mask */ > sigemptyset (&linuxthreads_wait_mask); > sigaddset (&linuxthreads_wait_mask, SIGCHLD); > > /* Use SIG_BLOCK to block receipt of SIGCHLD. > The block_mask will allow us to wait for this signal explicitly. */ > sigprocmask(SIG_BLOCK, > &linuxthreads_wait_mask, > &linuxthreads_block_mask); > > What this code fails to take into account is what happens if SIGCHLD is > already being blocked. (Perhaps set that way from some other part of > gdb.) If this is the case, then setting linuxthreads_block_mask to > the old signal mask (prior to blocking the SIGCHLD with SIG_BLOCK) > results in a mask with SIGCHLD blocked. > > This is clearly a problem because the loop noted above will get stuck > in sigsuspend() if it doesn't manage to find a change in a child status > on the first iteration. > > This leads me to the patch below and I hereby request approval for > committing it. I have run the test suite on Linux and have observed > no regressions as a result of this change. > I privately discussed the SIGCHLD management point with Michael, as this was one major change in the LinuxThread support behaviour I wrote code for. My only problem with your patch is that if SIGCHLD is blocked at that time, it should have been blocked intentionally by other part of GDB, and if SIGCHLD has not yet been unblocked, then this is a bug to fix in the right part of GDB, and not in the LinuxThread support, because other parts of GDB dealing with SIGCHLD [un]masking will also have to support the fix you propose. So, I would suggest that (thanks to your program which exhibits consistently the problem) you try to track down the signal status in 'gdb_init()' and try to discover what part of GDB is incorrectly managing SIGCHLD. After having downloaded the latest GDB snapshot and looked at the source, I have not been able to see any place where the SIGCHLD is being blocked before calling '_initialize_linuxthreads()', but you should be able to discover that quickly with your test program (perhaps in the 'pre_init_ui_hook' if you use an UI). Could you just check that for me. Thanks in advance, -Eric +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Eric PAIRE Web : http://www.ri.silicomp.com/~paire | Group SILICOMP - Research Institute Email: eric.paire@ri.silicomp.com | 2, avenue de Vignate Phone: +33 (0) 476 63 48 71 | F-38610 Gieres Fax : +33 (0) 476 51 05 32 | FRANCE