[PATCH RFA?] solib.c hack

[Andrew Cagney]

Kevin Buettner wrote:
> 
> I found that the following hack was needed for to get gdb to run a
> program on i586-sco-sysv5uw7.1.0.  It seems to me that the real
> problem could be in the toolchain which generated the executable, but
> I also think that it's not unreasonable to place a limit on the value
> that ``storage_needed'' can take on.
> 
> Okay to apply?
> 
> (I have misgivings about this patch myself, so I'll understand if it's
> rejected.)

Its really a shared library maintainer question however, shouldn't BFD
be the thing that is responsible for ensuring that the value returned is
correct?  Now a days 6mb isn't that much.

	Andrew


> Index: solib.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/solib.c,v
> retrieving revision 1.22
> diff -u -p -r1.22 solib.c
> --- solib.c     2000/08/31 00:39:10     1.22
> +++ solib.c     2000/09/18 17:43:57
> @@ -648,6 +648,13 @@ bfd_lookup_symbol (bfd *abfd, char *symn
> 
>    storage_needed = bfd_get_dynamic_symtab_upper_bound (abfd);
> 
> +  /* Hack for Unixware.  The upper bound being returned on Unixware was
> +     0xffffffff and gdb got an out-of-memory error attempting to allocate
> +     this much memory. */
> +#define REASONABLE_LIMIT 6000000
> +  if (storage_needed > REASONABLE_LIMIT)
> +    storage_needed = REASONABLE_LIMIT;
> +
>    if (storage_needed > 0)
>      {
>        symbol_table = (asymbol **) xmalloc (storage_needed);