From: Eli Zaretskii <eliz@gnu.org>
To: Guinevere Larsen <guinevere@redhat.com>
Cc: aburgess@redhat.com, gdb-patches@sourceware.org
Subject: Re: [PATCH] gdb, configure: Add disable-formats option for configure
Date: Mon, 07 Oct 2024 22:17:08 +0300 [thread overview]
Message-ID: <86a5ffu3ij.fsf@gnu.org> (raw)
In-Reply-To: <b95142f1-e49b-4c6a-ab07-988005e1618e@redhat.com> (message from Guinevere Larsen on Mon, 7 Oct 2024 15:30:37 -0300)
> Date: Mon, 7 Oct 2024 15:30:37 -0300
> Cc: gdb-patches@sourceware.org
> From: Guinevere Larsen <guinevere@redhat.com>
>
> > And a more practical question: if I want to build GDB that will run on
> > GNU/Linux and should be able to debug Linux executables natively and
> > MS-Windows executables via gdbserver, which formats should I specify
> > with this new --enable-formats option?
>
> Linux uses elf files, and windows uses PE-coff (compiled when coff is
> requested), so you would need --enable-formats=elf,coff
>
> However, with the patch as-is in the list, any value you put in there
> (including --enable-formats=no, which would add nothing user selected)
> would compile support for elf and coff anyway, so there is no need to worry.
>
> Finally, if you aren't sure, the default behavior if the flag is to
> compile all readers, keeping with the old behavior.
I presume users and packagers will want to use this feature to avoid
compiling in stuff they will never need. The problem, as I see it, is
that it is hard to decide what to specify, and your answer to my
Linux+Windows question illustrates this very well.
By contrast, the security benefits might not be interesting at least
to some.
> > See, I think these are the questions that the readers of the manual
> > will ask themselves, and we should have the answers there for them.
> >
> That's a reasonable point. I don't think we should need to document all
> targets, but I can see the value of documenting the main usage of the
> file format when describing the options, as a guideline for users
> running on mainstream platforms and not meant as an exhaustive list. I'm
> thinking of adding the following to the readme:
>
> `--enable-binary-file-format=FORMAT,FORMAT...'
> `--enable-binary-file-format=all'
> Configure GDB to only be be able to read selected file formats.
> The special value "all" causes all file formats to be compiled in,
> and is the
> the default behavior of the option. The other possible options are:
> * coff: Main format on windows systems. This is required to compile with
> windows target support;
> * dbx: (also known as a.out), is a legacy file format, this is
> recommended
> if you know you will be dealing with this file format;
> * elf: Main format of linux systems. This is heavily recommended when
> compiling with linux support;
> * macho: Main format on MacOS systems, this is heavily recommended
> when compiling for those targets;
> * mips: (also known as ecoff), this is the main file format for targets
> running on MIPS CPUs. It is heavily recommended when supporting those
> targets.
> * xcoff: Main format of AIX systems, this is required to compile for AIX
> targets and rs6000 CPUs.
>
>
> What do you think?
That's a good starting point, but IMO it stops short of answering the
practical questions people will ask themselves. For example, how do I
configure GDB to support a single target that is my native target and
OS? will specifying the single format from the above list do?
One thing I remember is that many targets produce core files in ELF
format. If that is true, then omitting ELF should be discouraged for
that reason. And maybe also other similar practical factoids.
next prev parent reply other threads:[~2024-10-07 19:17 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-25 17:53 Guinevere Larsen
2024-09-26 5:49 ` Eli Zaretskii
2024-09-26 18:16 ` Guinevere Larsen
2024-09-26 18:35 ` Eli Zaretskii
2024-09-26 21:03 ` Guinevere Larsen
2024-09-27 6:05 ` Eli Zaretskii
2024-10-02 13:25 ` Andrew Burgess
2024-10-02 14:15 ` Eli Zaretskii
2024-10-04 14:26 ` Andrew Burgess
2024-10-04 14:45 ` Eli Zaretskii
2024-10-07 18:30 ` Guinevere Larsen
2024-10-07 19:17 ` Eli Zaretskii [this message]
2024-10-07 19:58 ` Guinevere Larsen
2024-10-08 11:44 ` Eli Zaretskii
2024-10-08 13:03 ` Guinevere Larsen
2024-10-08 13:21 ` Eli Zaretskii
2024-10-10 14:45 ` Guinevere Larsen
2024-10-10 16:10 ` Andrew Burgess
2024-09-26 19:18 ` Tom Tromey
2024-09-26 19:49 ` Guinevere Larsen
2024-09-27 18:01 ` Tom Tromey
2024-10-02 13:56 ` Andrew Burgess
2024-10-02 20:37 ` Guinevere Larsen
2024-10-03 10:15 ` Andrew Burgess
2024-10-04 14:49 ` Andrew Burgess
2024-10-10 20:18 ` Guinevere Larsen
2024-10-16 10:50 ` Andrew Burgess
2024-10-16 21:00 ` Guinevere Larsen
2024-10-17 19:43 ` Tom Tromey
2024-10-17 19:48 ` Guinevere Larsen
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=86a5ffu3ij.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=aburgess@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=guinevere@redhat.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