From: "Maciej W. Rozycki" <macro@orcam.me.uk>
To: Simon Marchi <simon.marchi@efficios.com>
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: Mon, 5 Jan 2026 08:07:37 +0000 (GMT) [thread overview]
Message-ID: <alpine.DEB.2.21.2601050137260.45251@angie.orcam.me.uk> (raw)
In-Reply-To: <02b08b9d-7478-4901-9230-0e4c6bb6d726@efficios.com>
On Sat, 3 Jan 2026, Simon Marchi wrote:
> >> 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'm fine myself, thank you, just even busier and more distracted than
usual.
> 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 :(.
My early MIPS experience certainly overlaps with the era (even MIPS/COFF,
as in ULTRIX/MIPS), but I never got into the details back then. At least
I usually know where to look for when chasing bits now.
The mdebug spec continues living online I believe, though it could be at
archive.org only nowadays; I can check. I have a local copy for anyone
needing it too. Yes, it does refer Third Eye Software.
> 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.
As I say I'll see what I can do. Overall emitting ECOFF-in-ELF frame
unwinding information aka Procedure Description Records (PDR), a valuable
subset of the mdebug stuff, continues being supported by MIPS GCC and GAS.
No other stuff is relevant anymore; we have no support for IRIX or ULTRIX
targets left and the GNU tools can't produce other ECOFF debug information
for MIPS targets anymore.
NB I had plans/ideas to improve PDR handling in GDB, but this has never
materialised. It's good having/improving IMHO as PDR records are very
lightweight and retained by `strip', and with its variable frame format
the MIPS target is very bad for debugging when execution is stopped at a
random place with no associated debug information, which might be libc or
suchlike. Then you just have the PC and the register stack available and
nothing else, not even the return address ($ra may have been clobbered).
But all the PDR support is gone from GDB AFAICT and ISTR now having a
discussion as to bringing it back some 20 years ago while I was still at
MTI, possibly with Daniel Jacobowitz. The messages should be easy to
chase, but otherwise I have to conclude none of this is relevant to MIPS
targets anymore. So I guess I've figured it out for you already.
This stuff is possibly used by the Alpha target however, though I'm not
sure offhand as I'm less familiar with the matters there.
HTH,
Maciej
next prev parent reply other threads:[~2026-01-05 8:08 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
2026-01-05 8:07 ` Maciej W. Rozycki [this message]
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=alpine.DEB.2.21.2601050137260.45251@angie.orcam.me.uk \
--to=macro@orcam.me.uk \
--cc=gdb-patches@sourceware.org \
--cc=simon.marchi@efficios.com \
--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