Multiple personalities gdb?

Multiple personalities gdb?

[Elena Zannoni]

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

The first is used to determine the size of the sections array in
the objfile structure:
struct stab_section_info
  {
    char *filename;
    CORE_ADDR sections[SECT_OFF_MAX];
    struct stab_section_info *next;
    int found;			/* Count of times it's found in searching */
  };


The second is used to store the information from which the
objfile->section_offsets are filled up:

struct section_addr_info {
  struct other_sections
  {
    CORE_ADDR addr;
    char *name;
    int sectindex;
  } other[MAX_SECTIONS];
};

while for section_offsets we have:

struct section_offsets
  {
    CORE_ADDR offsets[1];	/* As many as needed. */
  };

Should MAX_SECTIONS == SECT_OFF_MAX ?

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.

Elena

Re: Multiple personalities gdb?

[Kevin Buettner]

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.)

> 
> 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;
    ...

Re: Multiple personalities gdb?

[Elena Zannoni]

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

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 <ac131313@cygnus.com>
To: GDB Discussion <gdb@sourceware.cygnus.com>
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 <kettenis@wins.uva.nl>
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 <ezannoni@cygnus.com>
   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 <kettenis@wins.uva.nl>
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 <edumas@tumbleweed.com>

   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 <robertl@sco.com>
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 <edumas@tumbleweed.com>
To: Mark Kettenis <kettenis@wins.uva.nl>
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)
<root> io:/opt/foo/bin fg
/export/home/gnu/bin/gdb TestMe
---Type <return> to continue, or q <return> 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