From: Tom Tromey <tom@tromey.com>
To: simon.marchi@polymtl.ca
Cc: gdb-patches@sourceware.org, Simon Marchi <simon.marchi@efficios.com>
Subject: Re: [PATCH] gdb: replace msym_bunch with deque
Date: Wed, 17 Dec 2025 09:01:11 -0700 [thread overview]
Message-ID: <87jyylyu60.fsf@tromey.com> (raw)
In-Reply-To: <20251217043141.1790384-1-simon.marchi@polymtl.ca> (simon marchi's message of "Tue, 16 Dec 2025 23:31:39 -0500")
>>>>> "Simon" == simon marchi <simon.marchi@polymtl.ca> writes:
Simon> An std::deque implementation typically uses a sequence of fixed-sized
Simon> arrays, much like our current msym_bunch implementation. So adding an
Simon> item at the end will not invalidate existing references. But unlike our
Simon> msym_bunch, we don't have to worry about memory management.
FWIW we have another instance of this idiom in buildsym.
Simon> I am a bit puzzled about this code in
Simon> minimal_symbol_reader::record_full:
Simon> I am not sure when minsyms_read would already be true when reading
Simon> minimal symbols, and if we should do anything differently here.
It's been a long time since I worked on this, but IIRC there were
readers where minimal symbol reading was mixed with partial symbol reading.
In these cases we could reuse the already-read minimal symbols but not
the partial symbols. This code, and the check in
minimal_symbol_reader::install, were there to allow the reuse without
creating new symbols.
The particular check you highlighted is just based on the idea that the
code is still trying to create a minimal symbol, but since it won't ever
be installed, there's no point to allocating more memory, we can just
reuse the same one over and over.
It's possible all this is obsolete given the stabs removal. You'd have
to investigate. But anyway all of this was a hack to avoid doing work
on these ancient / obsolete readers.
Simon> + /* The minimal symbols recorded so far. This uses a deque instead of e.g. a
Simon> + vector, because references to minimal symbols need to stay valid across
Simon> + calls to recod_full. */
Typo, "record_full"
Tom
next prev parent reply other threads:[~2025-12-17 16:01 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-17 4:31 simon.marchi
2025-12-17 16:01 ` Tom Tromey [this message]
2025-12-17 18:46 ` Tom Tromey
2025-12-17 19:58 ` Simon Marchi
2025-12-18 18:07 ` Tom Tromey
2025-12-18 18:09 ` Simon Marchi
2026-01-03 23:24 ` Maciej W. Rozycki
2026-01-04 4:09 ` Simon Marchi
2026-01-05 8:07 ` Maciej W. Rozycki
2026-01-05 19:05 ` Simon Marchi
2026-01-05 19:17 ` Tom Tromey
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=87jyylyu60.fsf@tromey.com \
--to=tom@tromey.com \
--cc=gdb-patches@sourceware.org \
--cc=simon.marchi@efficios.com \
--cc=simon.marchi@polymtl.ca \
/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