From: Simon Marchi <simon.marchi@efficios.com>
To: "Maciej W. Rozycki" <macro@orcam.me.uk>
Cc: Tom Tromey <tom@tromey.com>,
Simon Marchi <simon.marchi@polymtl.ca>,
gdb-patches@sourceware.org
Subject: Re: [PATCH] gdb: replace msym_bunch with deque
Date: Sat, 3 Jan 2026 23:09:05 -0500 [thread overview]
Message-ID: <02b08b9d-7478-4901-9230-0e4c6bb6d726@efficios.com> (raw)
In-Reply-To: <alpine.DEB.2.21.2601032316180.14570@angie.orcam.me.uk>
On 2026-01-03 18:24, Maciej W. Rozycki wrote:
> On Thu, 18 Dec 2025, Simon Marchi wrote:
>
>>> Simon> Indeed, I dug into that in the mean time. I'd like if someone with
>>> Simon> historical knowledge could fact-check me here.
>>>
>>> FWIW I suspect no such person exists.
>>
>> Given a lot of this is MIPS-specific, I was hoping that Maciej could be
>> able to help (adding in CC).
>
> I don't know offhand as it's stuff I haven't touched for ages now. I'll
> see what I can do. Also I can see you've pushed your change already, so I
> gather there's no rush. NB it was bad timing to get into this discussion
> as I had an emergency situation to handle and overall hectic time through
> recent weeks.
>
> Happy New Year for now!
Thanks for replying, hope all is well for you.
I pushed the patch because I convinced myself that the patch wouldn't
break the ECOFF-in-ELF case. Here is the relevant quote from my
previous message:
Ok, so I think that the consequence of my patch is that if you're
parsing ECOFF-in-ELF, then we'll allocate minimal symbols unnecessarily
in mdebugread's minimal_symbol_reader. They still won't get installed
because of the check in minimal_symbol_reader::install. They will get
freed when the minimal_symbol_reader gets destroyed. So that means
slightly higher memory usage for the duration of
elfmdebug_build_psymtabs, but no change in behavior. I can live with
that, so I'll go ahead and push the patch.
Of course, this is all based on my understanding, from the information I
gleaned here and there. It seems like not many people remember this era
nowadays :(.
What would help me, if you have time (no rush), is to tell me if we can
reasonably consider the code in mipsread.c (and mdebugread.c, which
seems related) to be obsolete and remove it.
Simon
next prev parent reply other threads:[~2026-01-04 4:10 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
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 [this message]
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=02b08b9d-7478-4901-9230-0e4c6bb6d726@efficios.com \
--to=simon.marchi@efficios.com \
--cc=gdb-patches@sourceware.org \
--cc=macro@orcam.me.uk \
--cc=simon.marchi@polymtl.ca \
--cc=tom@tromey.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