From mboxrd@z Thu Jan 1 00:00:00 1970 From: Elena Zannoni To: Kevin Buettner Cc: Elena Zannoni , gdb@sourceware.cygnus.com Subject: Re: Multiple personalities gdb? Date: Thu, 20 Apr 2000 14:26:00 -0000 Message-id: <14591.30185.259224.644126@kwikemart.cygnus.com> References: <14591.27151.916282.518234@kwikemart.cygnus.com> <1000420210435.ZM14571@ocotillo.lan> X-SW-Source: 2000-04/msg00115.html Kevin Buettner writes: > On Apr 20, 4:35pm, Elena Zannoni wrote: > > > I am wondering about these two constants: > > > > gdb-stabs.h:41:#define SECT_OFF_MAX 16 /* Count of possible values */ > > > > and > > > > symfile.h:64:#define MAX_SECTIONS 40 > > [...] > > > Should MAX_SECTIONS == SECT_OFF_MAX ? > > It seems reasonable. (But see below.) > Yes, it should definitely be changed, I am now looking at gdb debugging gdb itself. One of the shlib loaded has 17 sections, and in default_symfile_offests it allocates only 16 objfile->section_offsets, because it uses SECT_OFF_MAX. I'll do a mini patch just for this. > > > > As I understand it, SECT_OFF_MAX is the maximum value that a section > > index can have. Souldn't it at least be increased? I have seen > > sections with indexes higher than 16. > > I was the one who changed the value of MAX_SECTIONS recently. 40 > seemed big enough for my purposes, but in my opinion, this data > structure should really be dynamically sized/resized. > > Since you've been changing struct section_addr_info recently, maybe > you could change it a little bit more... Maybe to something along the > following lines: > > struct section_addr_info { > int num_sections; > struct section_addr_info_sections > { > CORE_ADDR addr; > char *name; > int sectindex; > } sections[1]; > }; > > Then when you need ``n'' sections, allocate as follows: > > struct section_addr_info saip; > > saip = xmalloc (sizeof (struct section_addr_info) > + (n - 1) * sizeof (struct section_addr_info_sections)); > saip->num_sections = n; > ... > > Yes, that should be done. When I get around to delete that 'other' array... I usually do things incrementally, otherwise I get very confused in my sandbox (Cagney docet!). Elena >From ac131313@cygnus.com Fri Apr 21 00:29:00 2000 From: Andrew Cagney To: GDB Discussion Subject: On line documentation updated Date: Fri, 21 Apr 2000 00:29:00 -0000 Message-id: <390002FE.3237899@cygnus.com> X-SW-Source: 2000-04/msg00116.html Content-length: 237 FYI, The online documentation should now be up-to-date (and will be updated daily). I'll also try to remember to push a copy of the documentation into the gdb/5.0 release web directory so that there is a stable version online. Andrew >From kettenis@wins.uva.nl Fri Apr 21 04:47:00 2000 From: Mark Kettenis To: ezannoni@cygnus.com Cc: kevinb@cygnus.com, ezannoni@cygnus.com, gdb@sourceware.cygnus.com Subject: Re: Multiple personalities gdb? Date: Fri, 21 Apr 2000 04:47:00 -0000 Message-id: <200004202146.e3KLkJZ00272@delius.kettenis.local> References: <14591.27151.916282.518234@kwikemart.cygnus.com> <1000420210435.ZM14571@ocotillo.lan> <14591.30185.259224.644126@kwikemart.cygnus.com> X-SW-Source: 2000-04/msg00118.html Content-length: 678 From: Elena Zannoni Date: Thu, 20 Apr 2000 17:26:01 -0400 (EDT) Yes, it should definitely be changed, I am now looking at gdb debugging gdb itself. One of the shlib loaded has 17 sections, and in default_symfile_offests it allocates only 16 objfile->section_offsets, because it uses SECT_OFF_MAX. Just another data point, my Linux libc (glibc 2.1.3-ish) has 60 sections. Of course GDB won't try to load all of these (a fairly large number of section is only present as part of a GNU-specific link-time warning system), but section 34 does contain some debugging info. So I guess this should definitely be dynamically allocated. Mark >From kettenis@wins.uva.nl Fri Apr 21 04:47:00 2000 From: Mark Kettenis To: edumas@tumbleweed.com Cc: gdb@sourceware.cygnus.com Subject: Re: gdb/Solaris2.6/C++/Multithred Date: Fri, 21 Apr 2000 04:47:00 -0000 Message-id: <200004202157.e3KLvX200283@delius.kettenis.local> References: <20000420141128.A3851@cliff.tumbleweed.com> X-SW-Source: 2000-04/msg00117.html Content-length: 526 Date: Thu, 20 Apr 2000 14:11:29 -0700 From: Eric Dumas Hello. I've got many problems to use gdb on an applications compiled with SunWorkshop4.2 on Solaris2.6. The application is multi-threaded (using the Solaris threading library). You could try a recent GDB snapshot. See http://sourceware.cygnus.com/gdb for more information. We're working towards a 5.0 release. The problem may already have been fixed, and if not we're interested to know if you can find out why! Mark >From robertl@sco.com Fri Apr 21 09:54:00 2000 From: Robert Lipe To: gdb@sourceware.cygnus.com Cc: nsd@cygnus.com Subject: GDB5 TOT on unixware 7 Date: Fri, 21 Apr 2000 09:54:00 -0000 Message-id: <20000421115138.A10096@rjlhome.sco.com> X-SW-Source: 2000-04/msg00119.html Content-length: 1262 I just spun the top of tree of the GDB5 branch on UnixWare 7. As a practical matter, the current thread support is somewhat more annoying than when GDB was thread-unaware. This GDB was configured as "i586-sco-sysv5uw7.1.1"... (gdb) run Starting program: /home/robertl/src/tmp/udiproto.timer/env/posix/./timertest [New LWP 1] [New Thread 1] [New Thread 2] [New Thread 3] [New Thread 4] [New LWP 2] [Exited Thread 2] [LWP 2 exited] [New LWP 3] procfs: fetch_registers, get_gregs line 3514, /proc/10235/lwp/2: No such file or directory. [Switching to LWP 2] procfs: fetch_registers, get_gregs line 3514, /proc/10235/lwp/2: No such file or directory. (gdb) c Continuing. procfs: fetch_registers, get_gregs line 3514, /proc/10235/lwp/2: No such file or directory. Note that at this point, it's trying to switch to an LWP that it knows has exited. The results are not good. But what happens next is even more annoying becuase now you're stuck in GDB and have to job control it and kill it. (gdb) q The program is running. Exit anyway? (y or n) y procfs: couldn't find pid 10235 in procinfo list. (gdb) q The program is running. Exit anyway? (y or n) y procfs: couldn't find pid 10235 in procinfo list. Nick, can you spot a ready fix for this? Thanx, RJL >From edumas@tumbleweed.com Fri Apr 21 10:13:00 2000 From: Eric Dumas To: Mark Kettenis Cc: edumas@tumbleweed.com, gdb@sourceware.cygnus.com Subject: Re: gdb/Solaris2.6/C++/Multithred Date: Fri, 21 Apr 2000 10:13:00 -0000 Message-id: <20000421101145.A8206@cliff.tumbleweed.com> References: <20000420141128.A3851@cliff.tumbleweed.com> <200004202157.e3KLvX200283@delius.kettenis.local> X-SW-Source: 2000-04/msg00120.html Content-length: 576 Using the last snapshot, Still some problems =-=-=-=-=-=-=-=-=-=-=-=-=-=-=- New LWP 19] [New LWP 20] [New LWP 21] [New LWP 22] Suspended (tty output) io:/opt/foo/bin fg /export/home/gnu/bin/gdb TestMe ---Type to continue, or q to quit--- [New LWP 23] [New LWP 24] =-=-=-=-=-=-=-=-=-=-=-=-=-=-=- After... the application no longer runs. -- Éric Dumas (Eric.Dumas@tumbleweed.com) Tumbleweed Communications, 700 Saginaw Drive, Redwood City, CA 94063, USA http://www.tumbleweed.com Tel: +1 650-216-2030