From: Simon Marchi <simon.marchi@polymtl.ca>
To: Tom Tromey <tom@tromey.com>
Cc: gdb-patches@sourceware.org, Simon Marchi <simon.marchi@efficios.com>
Subject: Re: [PATCH] gdb: replace msym_bunch with deque
Date: Wed, 17 Dec 2025 14:58:29 -0500 [thread overview]
Message-ID: <85958fad-17e1-4593-b842-d60a6610f149@polymtl.ca> (raw)
In-Reply-To: <87fr99ymhw.fsf@tromey.com>
On 12/17/25 1:46 PM, Tom Tromey wrote:
>>>>>> "Tom" == Tom Tromey <tom@tromey.com> 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 <tom@tromey.com>
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
next prev parent reply other threads:[~2025-12-17 19:59 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 [this message]
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
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=85958fad-17e1-4593-b842-d60a6610f149@polymtl.ca \
--to=simon.marchi@polymtl.ca \
--cc=gdb-patches@sourceware.org \
--cc=simon.marchi@efficios.com \
--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