Re: 'char **environ' woes with cygwin

[Chris Faylor <cgf@cygnus.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 21756 bytes --]

On Fri, Aug 25, 2000 at 11:25:32AM -0700, Michael Elizabeth Chastain wrote:
>Ok, here's a patch against sourceware that rips out the "environ" crap.
>I haven't even built with it.
>
>After doing the math, the fixed address "&environ" cancels out.  So this
>won't make things any worse (or better) for djgpp or other systems where
>malloc() does more than increment an sbrk pointer.
>
>Chris, do you think this makes your life easier enough to warrant some
>testing and integration into sourceware?

It doesn't really affect me.  I proposed eliminating the use of 'extern
char **environ' throughout gdb.  Your patch removes the extern... just
like mine does, so it's fine with me.

I do agree that we shouldn't be using environ like this, though, so
eliminating it is a good idea.

However, I tried your patch and it failed here on cygwin:

i686-pc-cygwin-gcc -c -g -O2    -I. -I/cygnus/src/sourceware/gdb -I/cygnus/src/sourceware/gdb/config -DHAVE_CONFIG_H -I/cygnus/src/sourceware/gdb/../include/opcode -I/cygnus/src/sourceware/gdb/../readline/.. -I../bfd -I/cygnus/src/sourceware/gdb/../bfd  -I/cygnus/src/sourceware/gdb/../include -I../intl -I/cygnus/src/sourceware/gdb/../intl -DGDBTK -Wimplicit -Wreturn-type -Wcomment -Wtrigraphs -Wformat -Wparentheses -Wpointer-arith -Wuninitialized  /cygnus/src/sourceware/gdb/event-top.c
/cygnus/src/sourceware/gdb/event-top.c: In function `command_handler':
/cygnus/src/sourceware/gdb/event-top.c:550: invalid operands to binary -
/cygnus/src/sourceware/gdb/event-top.c: In function `command_line_handler_continuation':
/cygnus/src/sourceware/gdb/event-top.c:582: invalid operands to binary -

Coercing 'sbrk(0)' to '(char *) sbrk(0)' fixed this.

cgf
From Fabrice_Gautier@sdesigns.com Fri Aug 25 12:49:00 2000
From: Fabrice Gautier <Fabrice_Gautier@sdesigns.com>
To: 'Daniel Berlin' <dan@cgsoftware.com>
Cc: "GDB (E-mail)" <gdb@sourceware.cygnus.com>
Subject: RE: Multi-thread debugging with eCos on i386 pc platform 
Date: Fri, 25 Aug 2000 12:49:00 -0000
Message-id: <8AE4B526B977D411841F00A0CC334020052C2D@cuz-exchange.sdesigns.net>
X-SW-Source: 2000-08/msg00148.html
Content-length: 421

> -----Original Message-----
> From: Daniel Berlin [ mailto:dan@cgsoftware.com ]
> Subject: RE: Multi-thread debugging with eCos on i386 pc platform 
> 
> Yup, i noticed this porting to BeOS.
> I have fixes for it.
> 
> > [...] Even more deeper, this is the read_fp() function that at 
>
> I fixed this too.

Cooool... 

And where are the fixes available? 

Thank you.
-- 
Fabrice Gautier
fabrice_gautier@sdesigns.com 
 
From ezannoni@cygnus.com Fri Aug 25 12:57:00 2000
From: Elena Zannoni <ezannoni@cygnus.com>
To: "John David Anglin" <dave@hiauly1.hia.nrc.ca>
Cc: gdb@sourceware.cygnus.com
Subject: Re: somread.c:480: invalid lvalue in assignment
Date: Fri, 25 Aug 2000 12:57:00 -0000
Message-id: <14758.53158.949196.765727@kwikemart.cygnus.com>
References: <200008251914.PAA11706@hiauly1.hia.nrc.ca>
X-SW-Source: 2000-08/msg00149.html
Content-length: 1346

John David Anglin writes:
 > Building the current CVS version of gdb under hpux 10.20 fails here:
 > 
 > gcc -c -O3  -D__HP_CURSES  -I. -I. -I./config -DHAVE_CONFIG_H -I./../include/opcode -I./../readline/.. -I../bfd -I./../bfd  -I./../include -I../intl -I./../intl  -Wimplicit -Wreturn-type -Wcomment -Wtrigraphs -Wformat -Wparentheses -Wpointer-arith -Wuninitialized  somread.c
 > somread.c: In function `som_symfile_read':
 > somread.c:362: warning: implicit declaration of function `init_import_symbols'
 > somread.c: In function `som_symfile_offsets':
 > somread.c:480: invalid lvalue in assignment
 > make[1]: *** [somread.o] Error 1
 > make[1]: Leaving directory `/xxx/gnu/gdb-5.0/gdb'
 > make: *** [all-gdb] Error 2
 > 
 > The offending line is:
 > 
 >       for (i = 0; i < SECT_OFF_MAX; i++)
 > 	      ANOFFSET (objfile->section_offsets, i) = text_addr;
 > 
 > Dave
 > -- 
 > J. David Anglin                                  dave.anglin@nrc.ca
 > National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Oops, my fault. Thanks for pointing it out. 
I'll commit a patch asap.
In the meantime you should change the line like this:

-       ANOFFSET (objfile->section_offsets, i) = text_addr;
+       (objfile->section_offsets)->offsets[i] = text_addr;

I'll get a proper patch in before the end of the day.

Elena
From dave@hiauly1.hia.nrc.ca Fri Aug 25 17:32:00 2000
From: "John David Anglin" <dave@hiauly1.hia.nrc.ca>
To: ezannoni@cygnus.com (Elena Zannoni)
Cc: gdb@sourceware.cygnus.com
Subject: Re: somread.c:480: invalid lvalue in assignment
Date: Fri, 25 Aug 2000 17:32:00 -0000
Message-id: <200008260032.UAA12611@hiauly1.hia.nrc.ca>
References: <14758.53158.949196.765727@kwikemart.cygnus.com>
X-SW-Source: 2000-08/msg00150.html
Content-length: 1685

Elena,

In case you didn't notice, the same problem occurs in somsolib.c and maybe
in other places.

Regards,
Dave
> 
> John David Anglin writes:
>  > Building the current CVS version of gdb under hpux 10.20 fails here:
>  > 
>  > gcc -c -O3  -D__HP_CURSES  -I. -I. -I./config -DHAVE_CONFIG_H -I./../include/opcode -I./../readline/.. -I../bfd -I./../bfd  -I./../include -I../intl -I./../intl  -Wimplicit -Wreturn-type -Wcomment -Wtrigraphs -Wformat -Wparentheses -Wpointer-arith -Wuninitialized  somread.c
>  > somread.c: In function `som_symfile_read':
>  > somread.c:362: warning: implicit declaration of function `init_import_symbols'
>  > somread.c: In function `som_symfile_offsets':
>  > somread.c:480: invalid lvalue in assignment
>  > make[1]: *** [somread.o] Error 1
>  > make[1]: Leaving directory `/xxx/gnu/gdb-5.0/gdb'
>  > make: *** [all-gdb] Error 2
>  > 
>  > The offending line is:
>  > 
>  >       for (i = 0; i < SECT_OFF_MAX; i++)
>  > 	      ANOFFSET (objfile->section_offsets, i) = text_addr;
>  > 
>  > Dave
>  > -- 
>  > J. David Anglin                                  dave.anglin@nrc.ca
>  > National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)
> 
> Oops, my fault. Thanks for pointing it out. 
> I'll commit a patch asap.
> In the meantime you should change the line like this:
> 
> -       ANOFFSET (objfile->section_offsets, i) = text_addr;
> +       (objfile->section_offsets)->offsets[i] = text_addr;
> 
> I'll get a proper patch in before the end of the day.
> 
> Elena
> 


-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)
From ezannoni@cygnus.com Fri Aug 25 17:42:00 2000
From: Elena Zannoni <ezannoni@cygnus.com>
To: "John David Anglin" <dave@hiauly1.hia.nrc.ca>
Cc: ezannoni@cygnus.com (Elena Zannoni), gdb@sourceware.cygnus.com
Subject: Re: somread.c:480: invalid lvalue in assignment
Date: Fri, 25 Aug 2000 17:42:00 -0000
Message-id: <14759.4732.282394.564068@kwikemart.cygnus.com>
References: <14758.53158.949196.765727@kwikemart.cygnus.com> <200008260032.UAA12611@hiauly1.hia.nrc.ca>
X-SW-Source: 2000-08/msg00151.html
Content-length: 1972

John David Anglin writes:
 > Elena,
 > 
 > In case you didn't notice, the same problem occurs in somsolib.c and maybe
 > in other places.
 > 
 > Regards,
 > Dave
 > > 


Sorry, the culprit is this patch:
http://sources.redhat.com/ml/gdb-patches/2000-08/msg00139.html

Will fix asap.

Elena

 > > John David Anglin writes:
 > >  > Building the current CVS version of gdb under hpux 10.20 fails here:
 > >  > 
 > >  > gcc -c -O3  -D__HP_CURSES  -I. -I. -I./config -DHAVE_CONFIG_H -I./../include/opcode -I./../readline/.. -I../bfd -I./../bfd  -I./../include -I../intl -I./../intl  -Wimplicit -Wreturn-type -Wcomment -Wtrigraphs -Wformat -Wparentheses -Wpointer-arith -Wuninitialized  somread.c
 > >  > somread.c: In function `som_symfile_read':
 > >  > somread.c:362: warning: implicit declaration of function `init_import_symbols'
 > >  > somread.c: In function `som_symfile_offsets':
 > >  > somread.c:480: invalid lvalue in assignment
 > >  > make[1]: *** [somread.o] Error 1
 > >  > make[1]: Leaving directory `/xxx/gnu/gdb-5.0/gdb'
 > >  > make: *** [all-gdb] Error 2
 > >  > 
 > >  > The offending line is:
 > >  > 
 > >  >       for (i = 0; i < SECT_OFF_MAX; i++)
 > >  > 	      ANOFFSET (objfile->section_offsets, i) = text_addr;
 > >  > 
 > >  > Dave
 > >  > -- 
 > >  > J. David Anglin                                  dave.anglin@nrc.ca
 > >  > National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)
 > > 
 > > Oops, my fault. Thanks for pointing it out. 
 > > I'll commit a patch asap.
 > > In the meantime you should change the line like this:
 > > 
 > > -       ANOFFSET (objfile->section_offsets, i) = text_addr;
 > > +       (objfile->section_offsets)->offsets[i] = text_addr;
 > > 
 > > I'll get a proper patch in before the end of the day.
 > > 
 > > Elena
 > > 
 > 
 > 
 > -- 
 > J. David Anglin                                  dave.anglin@nrc.ca
 > National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)
From kettenis@wins.uva.nl Sun Aug 27 08:35:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: gdb@sourceware.cygnus.com
Subject: Linux threads support
Date: Sun, 27 Aug 2000 08:35:00 -0000
Message-id: <200008271535.e7RFZZc04890@delius.kettenis.local>
X-SW-Source: 2000-08/msg00152.html
Content-length: 2066

After concluding that the current Linux threads support is pretty much
broken beyond repair, I have been working on a reimplementation, which
consists of two layers:

1. A Linux LWP layer.  This presents a group of Linux processes (which
   are assumed to share a single address space) to GDB as a
   multi-threaded process.  It should be useful on its right, i.e. for
   programs that don't use the LinuxThreads library, but the clone()
   system call directly.

2. A generic libthread_db layer (contains only a few Linux-specific
   hooks).  This contains much code from Michael Snyder's lin-thread.c
   module, but since most of the Linux-specific stuff is factored out
   into the Linux LWP layer, it should be possible to make it usable
   for Solaris without much problems.

The old LinuxThreads support contained linux-thread.c isn't there
anymore.  It shouldn't be too difficult to reimplement it, but I'm not
eager to do so.  Supporting one threads debugging module is bad enough.

Anyway, I'm now at a point where I think it functions better than the
current threads support, and I really need to get it more widely
tested.  I see two possibilities:

1. Post a patch and hope that people take the trouble of applying it.

2. Put the new code directly in the CVS (possible in a seperate
   branch).

I think option 1 is doomed to fail.  For option 2 I'd like some
opinions (especially from the maintainers of the various Linux ports):

* Should the stuff be checked in on a seperate branch?

* How important is support for older Linux systems (pre-libthread_db,
  i.e. pre glibc-2.1.3) give the fact that GDB has never had any
  satisfactory threads support for these systems, and older versions
  of the LinuxThreads library contain many critical bugs?

* Who needs to review this stuff?  Michael Snyder is listed as the
  threads maintainer and did the origional integration/implementation
  of the Linux threads support.  However, he seems to be pretty busy,
  and he once told me he isn't too familiar with the peculiarities of
  the Linux stuff.

Mark
From kevinb@cygnus.com Sun Aug 27 09:06:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: Mark Kettenis <kettenis@wins.uva.nl>, gdb@sourceware.cygnus.com
Subject: Re: Linux threads support
Date: Sun, 27 Aug 2000 09:06:00 -0000
Message-id: <1000827160616.ZM14856@ocotillo.lan>
References: <200008271535.e7RFZZc04890@delius.kettenis.local> <kettenis@wins.uva.nl>
X-SW-Source: 2000-08/msg00153.html
Content-length: 1384

On Aug 27,  5:35pm, Mark Kettenis wrote:

> Anyway, I'm now at a point where I think it functions better than the
> current threads support, and I really need to get it more widely
> tested.  I see two possibilities:
> 
> 1. Post a patch and hope that people take the trouble of applying it.
> 
> 2. Put the new code directly in the CVS (possible in a seperate
>    branch).
> 
> I think option 1 is doomed to fail.  For option 2 I'd like some
> opinions (especially from the maintainers of the various Linux ports):

I agree with you regarding option 1.  For option 2, I think you should
just check in your changes on the trunk.  It's scary, but I don't
think it'll get tested otherwise.

> * Should the stuff be checked in on a seperate branch?

As noted above, I don't think a separate branch would be advisable. 
In fact, I think it's be more likely that people would test your
changes if you posted a patch than if you created a branch with your
changes.

> * How important is support for older Linux systems (pre-libthread_db,
>   i.e. pre glibc-2.1.3) give the fact that GDB has never had any
>   satisfactory threads support for these systems, and older versions
>   of the LinuxThreads library contain many critical bugs?

I don't see any need to offer thread support for older Linux systems. 
gdb should still be able to debug non-threaded programs on these
systems though.
From listasagosto@waycom.com.ar Sun Aug 27 10:40:00 2000
From: listasagosto@waycom.com.ar
To: gdb@sourceware.cygnus.com
Subject: Despues no diga que no le avisamos !!
Date: Sun, 27 Aug 2000 10:40:00 -0000
Message-id: <219a8cc98cbff416ec0fdb7f4af65879@NO-ID-FOUND.mhonarc.org>
X-SW-Source: 2000-08/msg00154.html
Content-length: 5154

             * * * * *  I N C R E I B L E ! ! !  * * * * *

           ¿Sabía ud. que cuando envía e-mails masivos
           promocionando un producto o servicio,
           estadísticamente recibe una respuesta positiva del 3
           a 6 por mil ?

           ¿Le vendría bien a usted incorporar de 270 a 540
           nuevos clientes ?

           ¿Sabe que su única inversión para lograrlo es de
           $45, y que no necesita conocimientos previos sobre
           el tema?

           Si usted siempre quiso incursionar en el comercio
           electrónico y no sabe cómo hacerlo, nosotros le
           brindamos TODAS las herramientas necesarias para que
           pueda lograrlo.

           ¿Por qué usted no puede ganar dinero como tantas
           otras personas utilizando esta poderosa herramienta
           ?

       Antes de continuar, queremos hacer hincapié en un
       punto muy importante:

            LAS BASES DE DATOS QUE COMERCIALIZAMOS SON NUEVAS ,o
             sea, actualizadas (“FRESCAS” COMO SE LAS CONOCE EN
                                LA JERGA).
 NO SE DEJE ENGAÑAR, Y NO COMPRE BASES DE DATOS VIEJAS QUE NO SIRVEN PARA 
NADA!

ESTAS MISMAS BASES QUE NOSOTROS COMERCIALIZAMOS, OTROS LAS VENDEN POR $100 
O $130 !!!

           Si usted trabaja con bases de datos que no están
           actualizadas, como las que se acostumbran a
           comercializar por este medio, tendrá una efectividad
           muchísimo menor.

      ¿Qué le ofrecemos para que usted pueda lograr su
       objetivo?

            Un CD-ROM con:

             1.  Un programa muy sencillo y útil para que pueda
                realizar el envío masivo de e-mails, y llevar
                un control de los mails enviados, los pedidos
                de información y todo lo necesario para que
                usted no tenga que preocuparse por nada, mas
                que para presionar un par de teclas. Si utiliza
                un modem de 56K, este programa enviará unos
                16000 e-mails “PERSONALIZADOS” por hora!!!
             2.  Las instrucciones en castellano para utilizar
                el programa.
             3. Otro programa (secundario) que le permitirá
                ordenar las direcciones de e-mail.
             4. Y lo mas importante, nuestra base de datos
                “ACTUALIZADA”, “NUEVA” y “VIRGEN” de mas de 500
                mil direcciones de e-mail. Muchas de ellas
                están acompañadas del nombre del titular par
                poder personalizar cada e-mail (esto se hace en
                forma automática).

               Están todas ordenadas y separadas por región
           (Capital Federal, Gran Buenos Aires Norte, Sur y
           Oeste,  Provincia de Buenos Aires, Interior del
           país, etc.)

                        OBSEQUIO: agregamos 850 mil
                direcciones de e-mail de Latinoamérica y
                España, también ordenadas y clasificadas
                por país (Brasil, Bolivia, Chile,
                Colombia, Costa Rica, Cuba, Dominicana,
                Ecuador, España, Guatemala, Honduras,
                México, Nicaragua, Panamá, Paraguay, Perú,
                Puerto Rico, Salvador, Uruguay y
                Venezuela).

              *******************************************
           Este mismo paquete es vendido por la competencia a $100

             Y para cerrar la promoción, proponemos una oferta
                 especial por todo el paquete de $39 válida
                únicamente para pedidos recibidos antes del

             MARTES 28 de Agosto!!! (inclusive, último día)

                     * * * * *  $ 3 9 * * * * *

            * * * * *  I N C R E I B L E ! ! !  * * * * *

              ********************************************

           Los CDs serán enviados por Correo Argentino, y
           abonados por la modalidad contrarreembolso
           (agregando $3).
               Para hacer un pedido NO responda a este e-mail!
              Los pedidos serán recibidos PREFERENTEMENTE por
                                teléfono al

                     15-4036-2573 (de 13 a 20 hs.)
                           TODOS LOS DIAS
               INCLUYENDO FINES DE SEMANA Y FERIADOS
                   o a argentinaagosto@uol.com.ar

                indicando su nombre, teléfono de contacto y
               dirección exacta y completa (incluyendo código
                                  postal).


 
--------------------------------------------------------------------------
 Este mensaje se envía con la complacencia de la nueva legislación sobre
 correo electrónico: Por sección 301, parrafo (a)(2)(C) de S.1618. Bajo el
 decreto S.1618 titulo 3ro. Aprobado por el 105 congreso base de las
 normativas Internacionales sobre SPAM, este E-mail no podrá ser
 considerado  SPAM mientras incluya una forma de ser removido.

 Este mensaje será enviado por única vez, y si desea ser removido de
 nuestra  base de datos en forma definitiva, responda a este e-mail 
indicando
 "Remover" en el subject.
From lars@nocrew.org Tue Aug 29 04:48:00 2000
From: lars brinkhoff <lars@nocrew.org>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: PDP-10
Date: Tue, 29 Aug 2000 04:48:00 -0000
Message-id: <8566oke1a7.fsf@junk.nocrew.org>
References: <853djurgax.fsf@junk.nocrew.org> <39A641B6.25EDF1E1@cygnus.com>
X-SW-Source: 2000-08/msg00155.html
Content-length: 1023

Andrew Cagney <ac131313@cygnus.com> writes:
> lars brinkhoff wrote:
> > I'm delighted to read, in the first chapter of GDB Internals, that GDB
> > should be able to run everywhere.  Next year, I may be working on a
> > port to PDP-10, which is a 36-bit word-adressed machine.  It's running
> > the TOPS-20 operating system.  Does this seem to be possible?
> 
> It may take a little (lot of) work :-(  findvar.c contains:
> 
>   /* Basic byte-swapping routines.  GDB has needed these for a long
>      time...  All extract a target-format integer at ADDR which is LEN
>      bytes long.  */
> 
>   #if TARGET_CHAR_BIT != 8 || HOST_CHAR_BIT != 8
>     /* 8 bit characters are a pretty safe assumption these days, so we
>        assume it throughout all these swapping routines.  If we had to
>        deal with 9 bit characters, we would need to make len be in bits
>        and would have to re-write these routines...  */
>   you lose
>   #endif

I'm willing to give it a try.  Would it be acceptable for inclusion in
GDB?
From Fabrice_Gautier@sdesigns.com Tue Aug 29 15:37:00 2000
From: Fabrice Gautier <Fabrice_Gautier@sdesigns.com>
To: "GDB (E-mail)" <gdb@sourceware.cygnus.com>
Subject: GDB internals: thread infos
Date: Tue, 29 Aug 2000 15:37:00 -0000
Message-id: <8AE4B526B977D411841F00A0CC334020052C33@cuz-exchange.sdesigns.net>
X-SW-Source: 2000-08/msg00156.html
Content-length: 1199

Hi,

I'm trying to understand how gdb retrieve thread information, thread frame
and thread pc.

I started in the info_threads_command  function.

So there in order to retrieve thread $pc it call the
functionswitch_to_thread which I presume do only a frame switch.

So here is this function:

static void
switch_to_thread (pid)
     int pid;
{
  if (pid == inferior_pid)
    return;

  inferior_pid = pid;
  flush_cached_frames ();
  registers_changed ();
  stop_pc = read_pc ();
  select_frame (get_current_frame (), 0);
}

I assume that inferior_pid should contain the thread id of the current
selected thread.
Then I have a few questions:

What does the registers_changed() should do and where is it defined?

Which pc does the read_pc command should return? The one of the inferior_pid
thread ?

Then in the get_current_frame function, it ends up calling:
	current_frame = create_new_frame (read_fp (), read_pc ());

What frame pointer should read_fp() return? I presume this is the one of the
thread we are switching too. right?
idem for read_pc(). But at what point is there an interaction with the
target to get effectively those values.

-- 
Fabrice Gautier
fabrice_gautier@sdesigns.com