This is the mail archive of the gdb-patches@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]

Re: [PATCH] Use mmap for symbol tables


> Sorry, "great idea" meant "clever way of satisfying the constraints
> Eirik has set";

I thought "great idea" seemed a bit over the top when I first read it;
"nifty hack" might be a bit closer.  :-)

> I suggested mapping individual sections at the front, but Eirik said
> he wasn't interested in implementing that.

I'm not sure I put it that strongly.  I certainly haven't implemented it
yet, because I prefer the simplest approach which works.  Given a choice
between a simple patch which works well for my problem space and doing
without because I don't have the energy to complicate things enough to
avoid wasting some virtual address space (a minor amount really, in the
particular context I was operating in), the simple patch won.

This discussion has also included the more general issue of whether
using mmap is the right answer in the first place.  If the answer to
that more fundamental question is no, the other details really don't
much matter.  :-)

I think I've already convinced myself (with much appreciated help from
this thread) that making mmap the default way of reading symbol tables
in GDB is probably not the right answer.  I would even go so far as to
say I'm not convinced there are enough people who can benefit from it to
make it a standard part of GDB (although I haven't given up on that
yet).  But if nothing else, posting my patch at least gives others in
similar situations (huge symbol tables which "never" disappear with a
strong likelihood of multiple concurrent GDB sessions on the same symbol
table) an alternative to filling up their swap space.  Perhaps the best
argument in favor of including this in the distribution, in some fashion
(with or without the extra complication to conserve address space),
disabled by default, is that not everyone who might benefit from this
approach pays attention to this mailing list.

If it would substantially improve the chances of including mmap support
(optional at both compile time and runtime) in the GDB distribution, I'd
be willing to take a crack at adding the complication to mmap only stuff
that GDB reads anyway.  And either way I still need to look at the
symfile_relocate_debug_section question, and fill in the gaps (the
configure hooks and documentation and test cases).  Plus I intend to
perform more timing experiments (including symbol tables on local disk).


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