Re: Initialization of hpux_threads

[Andrew Cagney <ac131313@cygnus.com>]

Michael Snyder wrote:
> 
> John David Anglin wrote:
> >
> > Thu Mar 16 16:49:27 EST 2000  John David Anglin  <dave@hiauly1.hia.nrc.ca>
> >
> >         * configure.in: Don't call _initialize_hpux_thread twice.
> >         * configure: \x18\x13
> >
> > --- configure.in.orig   Mon Mar  6 18:30:12 2000
> > +++ configure.in        Thu Mar 16 14:22:26 2000
> > @@ -330,7 +330,6 @@
> >              AC_DEFINE(HAVE_HPUX_THREAD_SUPPORT)
> >              CONFIG_OBS="${CONFIG_OJS} hpux-thread.o"
> >              CONFIG_SRCS="${CONFIG_SRCS} hpux-thread.c"
> > -           CONFIG_INITS="${CONFIG_INITS} hpux-thread.c"
> >           else
> >              AC_MSG_RESULT(no (suppressed because you are not using GCC))
> >           fi
> 
> If someone from HP will approve this, I will check it in...

No need, I've checked it in.  The problem was that init.c was being
generated with two calls to ..._hpux_thread.
Thanks,
	Andrew
Mon Mar 20 17:33:32 2000  Andrew Cagney  <cagney@b1.cygnus.com>

	From Thu Mar 16 16:49:27 EST 2000 John David Anglin
 	<dave@hiauly1.hia.nrc.ca>:
	* configure.in (CONFIG_INITS): Don't include hpux-thread.c.

Index: configure.in
===================================================================
RCS file: /cvs/src/src/gdb/configure.in,v
retrieving revision 1.11
diff -p -r1.11 configure.in
*** configure.in	2000/03/05 22:57:05	1.11
--- configure.in	2000/03/20 06:35:10
*************** if test ${build} = ${host} -a ${host} = 
*** 330,336 ****
              AC_DEFINE(HAVE_HPUX_THREAD_SUPPORT)
              CONFIG_OBS="${CONFIG_OJS} hpux-thread.o"
              CONFIG_SRCS="${CONFIG_SRCS} hpux-thread.c"
! 	    CONFIG_INITS="${CONFIG_INITS} hpux-thread.c"
           else
              AC_MSG_RESULT(no (suppressed because you are not using GCC))
           fi
--- 330,336 ----
              AC_DEFINE(HAVE_HPUX_THREAD_SUPPORT)
              CONFIG_OBS="${CONFIG_OJS} hpux-thread.o"
              CONFIG_SRCS="${CONFIG_SRCS} hpux-thread.c"
! 	    #CONFIG_INITS="${CONFIG_INITS} hpux-thread.c"
           else
              AC_MSG_RESULT(no (suppressed because you are not using GCC))
           fi
From ac131313@cygnus.com Sun Mar 19 22:56:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Philippe GIACINTI <Philippe.Giacinti@sxb.bsf.alcatel.fr>
Cc: gdb-patches@sourceware.cygnus.com, Michael Snyder <msnyder@cygnus.com>
Subject: Re: [PATCH] minor fixes in remote.c
Date: Sun, 19 Mar 2000 22:56:00 -0000
Message-id: <38D5CB49.6F9CF39@cygnus.com>
References: <14549.49859.878539.158465@gargle.gargle.HOWL>
X-SW-Source: 2000-03/msg00362.html
Content-length: 1918

Philippe GIACINTI wrote:
> 
> Hi,
> 
> Here is a patch including minor fixes in file gdb/remote.c:
> 
>      * remote.c (record_currthread): must call `set_thread' to change
>      general thread, in order to let stub know we have changed it.
>      * remote.c (remote_read_bytes): when we need to read more memory
>      than max buffer size, we have to reserve space for leading $ and
>      trailing # + checksum (i.e.: 4 char)
> 
> Best regards.
> --
> Philippe Giacinti - Alcatel Business Systems - PCD/SMB/SWPCC - CC S0645
> 1, route du Dr Albert Schweitzer - 67408 Illkirch Cedex - FRANCE
> Tel: +33 (0)3.90.67.62.10 - Fax: +33 (0)3.90.67.77.93
> mailto:Philippe.Giacinti@sxb.bsf.alcatel.fr
> 
>   ------------------------------------------------------------------------
> --- insight-20000314.old/gdb/remote.c   Fri Feb 18 18:00:18 2000
> +++ insight-20000314/gdb/remote.c       Fri Mar 17 09:00:54 2000

FYI,

> @@ -742,7 +742,7 @@
>  record_currthread (currthread)
>       int currthread;
>  {
> -  general_thread = currthread;
> +  set_thread (currthread,1);
> 
>    /* If this is a new thread, add it to GDB's thread list.
>       If we leave it up to WFI to do this, bad things will happen.  */

This is more MichaelS's domain.

> @@ -3439,7 +3439,8 @@
>        int todo;
>        int i;
> 
> -      todo = min (len, max_buf_size / 2);      /* num bytes that will fit */
> +      todo = min (len, max_buf_size / 2 - 4);  /* num bytes that will fit */
> +      /* -4 for leading $ and trailing # + checksum (2 hex chars) */
> 
>        /* construct "m"<memaddr>","<len>" */
>        /* sprintf (buf, "m%lx,%x", (unsigned long) memaddr, todo); */
> --- insight-20000314.old/gdb/ChangeLog  Tue Mar 14 03:37:24 2000
> +++ insight-20000314/gdb/ChangeLog      Fri Mar 17 13:29:21 2000

Can you expand on this one a little?
There were several nasty buffer overflow bugs but they should have been
fixed.

	Andrew
From Philippe.Giacinti@sxb.bsf.alcatel.fr Sun Mar 19 23:38:00 2000
From: Philippe GIACINTI <Philippe.Giacinti@sxb.bsf.alcatel.fr>
To: gdb-patches@sourceware.cygnus.com
Subject: [PATCH] update: minor fixes in remote.c
Date: Sun, 19 Mar 2000 23:38:00 -0000
Message-id: <14549.54618.39052.823724@gargle.gargle.HOWL>
X-SW-Source: 2000-03/msg00363.html
Content-length: 1813

Hi,

Here is an update of my previous patch + some explanations:

@@ -742,7 +742,7 @@
 record_currthread (currthread)
      int currthread;
 {
-  general_thread = currthread;
+  set_thread (currthread,1);
 
   /* If this is a new thread, add it to GDB's thread list.
      If we leave it up to WFI to do this, bad things will happen.  */

This fix is very useful when you're remotely debugging a multi-threaded
program (I'm currently working with a prototype of gdbserver with support for
linuxthreads). If the remote side doesn't know that the general thread has
changed, then next `g' or `G' requests (get or write registers) will return
bad values (i.e.: registers values of old general thread).


@@ -3439,7 +3439,8 @@
       int todo;
       int i;
 
-      todo = min (len, max_buf_size / 2);	/* num bytes that will fit */
+      todo = min (len, max_buf_size / 2 - 2);	/* num bytes that will fit */
+      /* -2 for leading $ and trailing # + checksum (2 hex chars) */
 
       /* construct "m"<memaddr>","<len>" */
       /* sprintf (buf, "m%lx,%x", (unsigned long) memaddr, todo); */

If the host side needs to read for example 500 bytes and assuming that the
maximum buffer size is 400 chars, then without the fix, the remote side will
be asked to send min (500, 400/2)=200 bytes, its answer will then be:
   $ ... 200 hex encoded bytes = 400 chars #CS = 400 + 4 chars which is greater
than the max buffer size and will lead to an error from the host side.
So we need to subtract 4 chars (i.e.: 2 hex encoded bytes) from requested
number of bytes.

Best regards.
-- 
Philippe Giacinti - Alcatel Business Systems - PCD/SMB/SWPCC - CC S0645
1, route du Dr Albert Schweitzer - 67408 Illkirch Cedex - FRANCE
Tel: +33 (0)3.90.67.62.10 - Fax: +33 (0)3.90.67.77.93
mailto:Philippe.Giacinti@sxb.bsf.alcatel.fr