This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [PATCH RFA?] solib.c hack
- To: Kevin Buettner <kevinb at cygnus dot com>
- Subject: Re: [PATCH RFA?] solib.c hack
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Thu, 26 Oct 2000 00:47:59 +1100
- Cc: gdb-patches at sourceware dot cygnus dot com
- References: <1000918175700.ZM29948@ocotillo.lan>
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);