From: Eirik Fuller <eirik@hackrat.com>
To: Jim Blandy <jimb@red-bean.com>
Cc: David Anderson <davea@quasar.engr.sgi.com>, gdb-patches@sourceware.org
Subject: Re: [PATCH] Use mmap for symbol tables
Date: Wed, 01 Feb 2006 18:11:00 -0000 [thread overview]
Message-ID: <43E0F9B8.4040603@hackrat.com> (raw)
In-Reply-To: <8f2776cb0601311039r37c73f91s1433355e18eb5e56@mail.gmail.com>
> 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).
next prev parent reply other threads:[~2006-02-01 18:11 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-31 4:40 David Anderson
2006-01-31 5:00 ` Eirik Fuller
2006-01-31 5:34 ` Jim Blandy
2006-01-31 14:00 ` Daniel Jacobowitz
2006-01-31 18:39 ` Jim Blandy
2006-02-01 18:11 ` Eirik Fuller [this message]
2006-01-31 17:45 ` David Anderson
2006-01-31 18:24 ` Jim Blandy
-- strict thread matches above, loose matches on Subject: below --
2006-01-31 4:53 David Anderson
2006-01-29 23:36 Eirik Fuller
2006-01-30 5:04 ` Jim Blandy
2006-01-30 11:44 ` Eirik Fuller
2006-01-30 18:07 ` Jim Blandy
2006-01-30 18:59 ` Eirik Fuller
2006-01-30 22:11 ` Jim Blandy
2006-01-31 0:38 ` Eirik Fuller
2006-01-31 1:49 ` Jim Blandy
2006-01-31 3:12 ` Eirik Fuller
2006-01-31 21:48 ` Mark Kettenis
2006-02-01 17:52 ` Eirik Fuller
2006-02-01 6:04 ` Michael Snyder
2006-01-30 11:34 ` Andrew STUBBS
2006-01-30 11:42 ` Corinna Vinschen
2006-01-30 11:48 ` Andrew STUBBS
2006-01-31 2:23 ` Daniel Jacobowitz
2006-01-31 3:31 ` Eirik Fuller
2006-01-31 3:38 ` Daniel Jacobowitz
2006-02-07 22:05 ` Eirik Fuller
2006-02-20 15:52 ` Daniel Jacobowitz
2006-01-31 5:28 ` Jim Blandy
2006-01-31 13:59 ` Daniel Jacobowitz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=43E0F9B8.4040603@hackrat.com \
--to=eirik@hackrat.com \
--cc=davea@quasar.engr.sgi.com \
--cc=gdb-patches@sourceware.org \
--cc=jimb@red-bean.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox