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 To: 'Daniel Berlin' Cc: "GDB (E-mail)" 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 To: "John David Anglin" 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" 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 To: "John David Anglin" 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 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 To: Mark Kettenis , 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> 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 To: Andrew Cagney 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 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 To: "GDB (E-mail)" 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