Re: A revised patch for dlclose

[Mark Kettenis <kettenis@wins.uva.nl>]

   Date: Tue, 7 Mar 2000 12:08:00 -0800
   From: "H . J . Lu" <hjl@valinux.com>

   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 <ac131313@cygnus.com>
To: Jason Molenda <jsm@cygnus.com>
Cc: "J.T. Conklin" <jtc@redback.com>, 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 <ac131313@cygnus.com>
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 <ac131313@cygnus.com> 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 <kingdon@redhat.com>
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  <kingdon@redhat.com>

	* 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 <ac131313@cygnus.com>
To: Mark Kettenis <kettenis@wins.uva.nl>
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 <eliz@delorie.com>
> 
>    > From: Andrew Cagney <ac131313@cygnus.com>
>    >
>    > > --- 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 <eliz@delorie.com>
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 <ac131313@cygnus.com>
>
> > --- 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 <taylor@cygnus.com>
To: Fernando Nasser <fnasser@cygnus.com>
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 <fnasser@cygnus.com>

    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" <Peter.Schauer@regent.e-technik.tu-muenchen.de>
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  <pes@regent.e-technik.tu-muenchen.de>

	* 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 <paire@ri.silicomp.fr>
To: Kevin Buettner <kevinb@cygnus.com>
Cc: Jim Blandy <jimb@cygnus.com>, gdb-patches@sourceware.cygnus.com, Michael Snyder <msnyder@cygnus.com>
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