This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
[PATCH RFA?] solib.c hack
- To: gdb-patches at sourceware dot cygnus dot com
- Subject: [PATCH RFA?] solib.c hack
- From: Kevin Buettner <kevinb at cygnus dot com>
- Date: Mon, 18 Sep 2000 10:57:00 -0700
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.)
* solib.c (bfd_lookup_symbol): Place an upper bound on the
storage required to load the dynamic symtab as reported by
bfd.
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);