From: Tom Tromey <tom@tromey.com>
To: Tom de Vries via Gdb-patches <gdb-patches@sourceware.org>
Cc: Tom de Vries <tdevries@suse.de>
Subject: Re: [PATCH] [gdb/symtab] Add set/show always-read-ctf on/off
Date: Fri, 24 Feb 2023 12:33:54 -0700 [thread overview]
Message-ID: <87r0uehn8d.fsf@tromey.com> (raw)
In-Reply-To: <20230224123522.21756-1-tdevries@suse.de> (Tom de Vries via Gdb-patches's message of "Fri, 24 Feb 2023 13:35:22 +0100")
>>>>> "Tom" == Tom de Vries via Gdb-patches <gdb-patches@sourceware.org> writes:
Tom> The setting is off by default, preserving current behaviour.
Tom> A bit of background on the relevance of reading order: the formats have a
Tom> priority relationship between them, where reading earlier means lower
Tom> priority. By reading the format with the most detail last, we ensure it has
Tom> the highest priority, which makes sure that in case there is overlapping info,
Tom> the most detailed info is found. This explains the current reading order of
Tom> mdebug, stabs and dwarf2.
Tom> Add the unconditional reading of ctf before dwarf2, because it's less detailed
Tom> than dwarf2. The conditional reading of ctf is still done after the attempt to
Tom> read dwarf2, necessarily so because we only know whether there's dwarf2 after
Tom> we've tried to read it.
I'm sorry I didn't comment on the earlier thread.
I wonder if the current behavior is important. Why not just always read
all the debug info that gdb supports? This is how stabs+DWARF works and
it makes a certain kind of sense -- due to separate compilation, you can
wind up with an aggregate object (like an executable) where each
individual part was made differently.
That is, instead of the option, why not make it unconditional?
Tom
next prev parent reply other threads:[~2023-02-24 19:33 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-24 12:35 Tom de Vries
2023-02-24 19:33 ` Tom Tromey [this message]
2023-02-25 8:42 ` Tom de Vries
2023-02-25 12:34 ` Tom Tromey
2023-02-26 8:25 ` Tom de Vries
2023-03-02 1:56 ` Tom Tromey
2023-03-02 7:18 ` Tom de Vries
2023-03-02 9:38 ` Eli Zaretskii
2023-03-02 9:58 ` Tom de Vries
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=87r0uehn8d.fsf@tromey.com \
--to=tom@tromey.com \
--cc=gdb-patches@sourceware.org \
--cc=tdevries@suse.de \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).