Re: [RFA] rs6000-nat.c fix for large symtabs.

[Kevin Buettner <kevinb at cygnus dot com>]

On Apr 7,  5:44pm, glen mccready wrote:

> >On Apr 7,  2:42pm, glen mccready wrote:
> >
> >> Some processes have more than 64 load segments; in the past gdb
> >> would fail under these circumstances.  This patch should alleviate
> >> that problem by expanding the buffer if the ld_info won't fit.
> >> 
> >> Fri Apr  7 13:44:38 2000  glen mccready  <gkm@pobox.com>
> >> 
> >> 	* rs6000-nat.c (xcoff_relocate_symtab): Grow buffer if ptrace()
> >> 	  fails due to lack of space.
> >
> >[...]
> >
> >> !       ldi = (void *) alloca (load_segs * sizeof (*ldi));
> >> !       if (ldi == 0)
> >> ! 	perror_with_name ("xcoff_relocate_symtab");
> >
> >[...]
> >
> >> ! 	if (errno == ENOMEM)
> >> ! 	  load_segs *= 2;
> >
> >
> >What's the value of sizeof (*ldi) ?
> 
> 26 bytes, I believe.

My test program showed 28 bytes.  (I just wanted a rough idea though.)

> >I have concerns about growing the stack too large if we fail multiple
> >times.  I would prefer to see us use xmalloc() and free() in this
> >situation.  (Putting alloca() in a loop is generally not a good idea.)
> 
> I did, too, but given how infrequently this problem is run across
> I'd be surprised if the loop ever went through more than twice.

I agree with you.

Suppose we make it through the loop three times; Then the total amount
of stack space consumed for this data structure will be 12544 bytes
(28 * (64 + 128 + 256)).  If the stack can't accomodate 12K of growth
by this function, then it's not likely that the gdb process will have
long to live anyway.

Your fix is approved; please check it in.

......

BTW, in pondering whether to approve your change or not, I looked at
the rest of the gdb sources to see what kind of precedents have been
set in the use of alloca().  I found that dbxread.c / partial-stab.h
uses exactly the same sort of allocation strategy that you (Glen)
decided to employ for xcoff_relocate_symtab().  The data structures
psymtab_include_list and dependency_list have small initial alloca()
allocations and are grown using alloca() to allocate a space double
the size of the previous data structure.  The contents of the old
space are copied to the new space and the old space is forgotten
about.

Another interesting example may be found in coff_read_struct_type ()
in coffread.c.  In this function, a list is constructed by allocating
elements of the list via alloca() in a loop.  (A similar technique
is employed in hp-symtab-read.c and perhaps other places as well.)

I'll conclude by noting that having these precedents in our code
doesn't mean that it's wise to write new code this way.  In
particular, I would be concerned about any function which could
potentially allocate multiple megabytes of stack space via alloca().

Kevin