From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id ic8oAmRxW2l/fywAWB0awg (envelope-from ) for ; Mon, 05 Jan 2026 03:08:04 -0500 Received: by simark.ca (Postfix, from userid 112) id 0633C1E048; Mon, 05 Jan 2026 03:08:04 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED, RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 6E87D1E048 for ; Mon, 05 Jan 2026 03:08:03 -0500 (EST) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id C2FAD4BA2E24 for ; Mon, 5 Jan 2026 08:08:02 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C2FAD4BA2E24 Received: from angie.orcam.me.uk (angie.orcam.me.uk [78.133.224.34]) by sourceware.org (Postfix) with ESMTP id 27DFC4BA2E04 for ; Mon, 5 Jan 2026 08:07:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 27DFC4BA2E04 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=orcam.me.uk Authentication-Results: sourceware.org; spf=none smtp.mailfrom=orcam.me.uk ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 27DFC4BA2E04 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=78.133.224.34 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1767600458; cv=none; b=cfRw0oKXf7Ar77SMnEHwxgWs6Clgg6gBTHsuebBcJZsq9g8deC5x5sXzRho7XwLdakHiIUzJ814izFOL+qDd5E8Ije+EKqpaijqNnZ6VSfoQ2jOXbGkg7lKcN1TwS3Xoq+B+VO0Go9ucqdTZm96Y3QtmBih9sy48k4zyn6xVIwg= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1767600458; c=relaxed/simple; bh=Ksju53QDT0VRCrK+ZZm+ZD3HuB49LLeSjEs+IuH8iuU=; h=Date:From:To:Subject:Message-ID:MIME-Version; b=RSM6vbvjPD//fn8Pfym8kngl1yiydXZvp3B5rvl9euAR+PZrI5rNOhAHe6K8ReLss3T5uoPewiwQoEF7JDaS/hV65WkZ46NTV93pPbaikLrLLYmEFqBvLKkGtDTi7SvaauJ4Ct0To0RRyrYQo4sB4RPkGgV4NVqFk3Q32oEMuXw= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 27DFC4BA2E04 Received: by angie.orcam.me.uk (Postfix, from userid 500) id 3E3C692009C; Mon, 5 Jan 2026 09:07:37 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by angie.orcam.me.uk (Postfix) with ESMTP id 37E1292009B; Mon, 5 Jan 2026 08:07:37 +0000 (GMT) Date: Mon, 5 Jan 2026 08:07:37 +0000 (GMT) From: "Maciej W. Rozycki" To: Simon Marchi cc: Tom Tromey , Simon Marchi , gdb-patches@sourceware.org Subject: Re: [PATCH] gdb: replace msym_bunch with deque In-Reply-To: <02b08b9d-7478-4901-9230-0e4c6bb6d726@efficios.com> Message-ID: References: <20251217043141.1790384-1-simon.marchi@polymtl.ca> <87jyylyu60.fsf@tromey.com> <87fr99ymhw.fsf@tromey.com> <85958fad-17e1-4593-b842-d60a6610f149@polymtl.ca> <87jyyjmzo4.fsf@tromey.com> <5cc22d76-115f-4054-ba34-6006e6013f06@efficios.com> <02b08b9d-7478-4901-9230-0e4c6bb6d726@efficios.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org 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