This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug gdb/17133] gdb can't load libraries with >2G .debug_info sections
- From: "tromey at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Fri, 11 Jul 2014 15:52:01 +0000
- Subject: [Bug gdb/17133] gdb can't load libraries with >2G .debug_info sections
- Auto-submitted: auto-generated
- References: <bug-17133-4717 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=17133
Tom Tromey <tromey at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tromey at redhat dot com
--- Comment #4 from Tom Tromey <tromey at redhat dot com> ---
(In reply to Alan Modra from comment #0)
> dwarf2read.c:dwarf2_read_section uses obstack_alloc to allocate a buffer for
> section contents. I've just been looking at a gdb crash when trying to load
> a shared library with a .debug_info section of 0x825b9155 bytes.
>
> The trouble is that obstack_alloc takes an "int size" parameter. "size" is
> therefore negative and we go off the rails fairly quickly. See
> include/obstack.h.
>
> So we have a 2G limit, even when gdb is 64-bit.
I think the only reason this data is allocated on the obstack is
convenience -- it doesn't require any special work to free it.
However, it isn't inordinately hard to arrange for it to be
allocated some other way and then freed properly. I think it
just requires a bit of extra code in dwarf2_per_objfile_free.
This seems simpler and no worse than making obstacks 64-bit-clean,
though of course there may be other reasons to do that.
--
You are receiving this mail because:
You are on the CC list for the bug.