Re: [PATCH] gdb: replace msym_bunch with deque

Simon Marchi
2026-01-05T19:06:07Z

On 2026-01-05 03:07, Maciej W. Rozycki wrote:
> 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.

I dug a bit deeper and found these links. The last one is especially
useful to understand the history.

ECOFF spec
https://web.archive.org/web/20160305114748/http://h41361.www4.hp.com/docs/base_doc/DOCUMENTATION/V50A_ACRO_SUP/OBJSPEC.PDF

mdebug, on David Anderson's page
https://www.prevanders.net/#mdebug

mdebug spec (at least some version of it)
https://www.prevanders.net/Mdebug.ps

Note from Peter Rowell about mdebug
http://www.datahedron.com/mips.html
https://www.prevanders.net/mdebug.html (mirror)

>> 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.

Ok, thanks for the precious information.

> 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.

I am mostly convinced that none of this is relevant anymore. And if it
ever became relevant anymore for some reason, I think it would be better
to just start from scratch, given how much this has bit-rotten.

Simon