From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id KuJGK4gLQ2n69QUAWB0awg (envelope-from ) for ; Wed, 17 Dec 2025 14:59:04 -0500 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=polymtl.ca header.i=@polymtl.ca header.a=rsa-sha256 header.s=oct2025 header.b=iNtBkGDK; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id A12991E048; Wed, 17 Dec 2025 14:59: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.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 98F2F1E048 for ; Wed, 17 Dec 2025 14:59:03 -0500 (EST) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id 337604BA2E25 for ; Wed, 17 Dec 2025 19:59:03 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 337604BA2E25 Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=polymtl.ca header.i=@polymtl.ca header.a=rsa-sha256 header.s=oct2025 header.b=iNtBkGDK Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id C97C24BA2E05 for ; Wed, 17 Dec 2025 19:58:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C97C24BA2E05 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=polymtl.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=polymtl.ca ARC-Filter: OpenARC Filter v1.0.0 sourceware.org C97C24BA2E05 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=132.207.4.11 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1766001517; cv=none; b=meLYO3KkeqKhC+bomBm2JuG/77BSY2ckUB5YoUQF3y6XXhJvcjmJhEvFTnOPhHvtIbd4hZcuFLjCw2amVZw8IG3z/tS8nH+FxUX4kOWBHpKqeTYfEYSmEW3Be4m2Kb9azFK7TQN8IWmUjZIrig/GZn5wQ0BKVgUcUWOA1yJidmw= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1766001517; c=relaxed/simple; bh=x9X9biW+hGkV5zJaX/E3aAF0eTc/o92RFiZO/ZOgKO4=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=sXNErF+SmmrYRxMRpHFbarWNToLl2fprsO5+ZSdwqFzNY83cTOhAC1WbdL7/SMppaNbiXa5TWv3zv4Ms7SdnJR6GdbVyb11Ix73CDwsehNtfUZQ2jxhmRtFVcyrcM+ty0DRN5GCaBP5aBGdVj54plSFLhm8eozdiCBF8YQoJJQE= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C97C24BA2E05 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 5BHJwUCi181873 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 17 Dec 2025 14:58:35 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 5BHJwUCi181873 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=polymtl.ca; s=oct2025; t=1766001515; bh=ZFdq4n2miRjFrOvigU139m4GgRlVX4BPb61wnC2dDzE=; h=Date:Subject:To:Cc:From:In-Reply-To:From; b=iNtBkGDKEhkmH1j5KO9VriepjOe4fgbU7XmWvSa8hUrUTaKYry40PNVxG4xbImJuj 3zGcy4Ow8LEdESHz33oBz1oJVJRTwnNt2/zpbbGLfK3V5pGBR9greOUxuSDUWBjyyK V18juSOXmTI4Q9AXDuCqel6AjF1827HwY9/hnUm4cSj/2cR6NHm2U0GztYLq17Yt4l zRVBV2SFwHMqROEvaiuYV9y4m+NnRlZWtHy96oCr6RvMeMWKIggGMN1ARXVt0vYY2M 0c82gUDTXz+tzdTqdJeU79HKUJNn6Ik+MhB0DpX+cHo4zlt+WawUpydImpyHZkzKyL B0V6ajSvQDldA== Received: by simark.ca (Postfix) id 4E4E11E048; Wed, 17 Dec 2025 14:58:30 -0500 (EST) Message-ID: <85958fad-17e1-4593-b842-d60a6610f149@polymtl.ca> Date: Wed, 17 Dec 2025 14:58:29 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] gdb: replace msym_bunch with deque To: Tom Tromey Cc: gdb-patches@sourceware.org, Simon Marchi References: <20251217043141.1790384-1-simon.marchi@polymtl.ca> <87jyylyu60.fsf@tromey.com> <87fr99ymhw.fsf@tromey.com> Content-Language: fr From: Simon Marchi In-Reply-To: <87fr99ymhw.fsf@tromey.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Wed, 17 Dec 2025 19:58:30 +0000 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 12/17/25 1:46 PM, Tom Tromey wrote: >>>>>> "Tom" == Tom Tromey writes: > > Tom> It's possible all this is obsolete given the stabs removal. You'd have > Tom> to investigate. But anyway all of this was a hack to avoid doing work > Tom> on these ancient / obsolete readers. > > mdebugread.c seems to use this feature. Indeed, I dug into that in the mean time. I'd like if someone with historical knowledge could fact-check me here. My understanding is: - There is the ECOFF format, which based on COFF but also specifies a debug information format (is that what mdebug is?). ECOFF seems to have been used mostly on Alpha and MIPS, before being superseded by ELF somewhere around 2000. - During the transition from ECOFF to ELF, it was made possible to put ECOFF debug info inside ELF. - The ECOFF debug info format was eventually completely replaced by DWARF, in about the same time frame. So the situation that interests us is when you have ECOFF-in-ELF. We first read the ELF minimal symbols in elf_symfile_read, then go into elfmdebug_build_psymtabs. elfmdebug_build_psymtabs is able to generate minimal symbols (useful when you have ECOFF debug info in an ECOFF executable I presume), but in this case we don't want to have those minimal symbols, we already have the ELF ones. Hence the need for this "don't actually create minimal symbols if we already have minimal symbols". Here are some relevant comments. This on in elfmdebug_build_psymtabs: /* FIXME: It's not clear whether we should be getting minimal symbol information from .mdebug in an ELF file, or whether we will. Re-initialize the minimal symbol reader in case we do. */ And this one in parse_partial_symbols (also in mdebugread.c): /* ECOFF in ELF: For ECOFF in ELF, we skip the creation of the minimal symbols. The ECOFF symbols should be a subset of the Elf symbols, and the section information of the elf symbols will be more accurate. FIXME! What about Irix 5's native linker? By default, Elf sections which don't exist in ECOFF get put in ECOFF's absolute section by the gnu linker. Since absolute sections don't get relocated, we end up calculating an address different from that of the symbol's minimal symbol (created earlier from the Elf symtab). To fix this, either : 1) don't create the duplicate symbol (assumes ECOFF symtab is a subset of the ELF symtab; assumes no side-effects result from ignoring ECOFF symbol) 2) create it, only if lookup for existing symbol in ELF's minimal symbols fails (inefficient; assumes no side-effects result from ignoring ECOFF symbol) 3) create it, but lookup ELF's minimal symbol and use it's section during relocation, then modify "uniquify" phase to merge and eliminate the duplicate symbol (highly inefficient) I've implemented #1 here... Skip the creation of the minimal symbols based on the ECOFF symbol table. */ I'm thinking that ECOFF is ripe to get removed from GDB, given that it has been replaced with ELF/DWARF for about 25 years. That would mean removing: - mdebugread.c - mipsread.c Removing those would allow many more cleanups, I think. > BTW I meant to approve your patch. > Approved-By: Tom Tromey 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. Simon