public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
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

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