This is the mail archive of the gdb-prs@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug gdb/17133] gdb can't load libraries with >2G .debug_info sections


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]