Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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: Tue, 08 Oct 2024 14:44:36 +0300	[thread overview]
Message-ID: <861q0qu8d7.fsf@gnu.org> (raw)
In-Reply-To: <59157ccb-69cd-4d23-9e39-89bb211583f8@redhat.com> (message from Guinevere Larsen on Mon, 7 Oct 2024 16:58:16 -0300)

> Date: Mon, 7 Oct 2024 16:58:16 -0300
> Cc: aburgess@redhat.com, gdb-patches@sourceware.org
> From: Guinevere Larsen <guinevere@redhat.com>
> 
> On 10/7/24 4:17 PM, Eli Zaretskii wrote:
> > 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?
> 
> If a user wants to configure their native target, that is related to the 
> --target and --enable-target options. Not the file formats. This change 
> is not related to how a user decides to support any given CPU or 
> operating system, but rather, which binary files they wish GDB to be 
> able to understand. If the user knows they want Windows and Linux, but 
> don't know how to specify that, they should look at documentation for 
> --target and --enable-targets, which is not touched by this patch or 
> related to this change whatsoever.

I think there's a misunderstanding.  I said "to support a single
target", meaning _only_ that single target.

You seem to be saying that --target is what I want, but that's not
what I knew.  Right now, when I compile GDB for native Windows
debugging, I get all the *read.c files compiled and linked into GDB.
I don't specify --target when I build GDB, but I do specify --build,
and I thought that --build=FOO is a short for --host=FOO --target=FOO.
So I thought that I am already specifying --target, and yet I get all
the binary-format readers compiled and linked in.  So I was asking
what should I do at configure time to have only the *read.c files I
need for that single target and only for native debugging.

If you are saying that the --enable-binary-format is unrelated to my
questions, then I guess I'm even more confused than I thought I was.

> > 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.
> >
> I believe that is the case because there are many targets that use ELF 
> as the objfile format.

True, but not what I was saying: I was specifically alluding to
targets whose objfile format is _not_ ELF, and yet they produce core
files in ELF format.  ISTR that Cygwin is one such target?  I'm sure
others here will be able to find more examples.

> And once again, users don't need to interact with this feature. If it is 
> completely ignored, GDB will continue to work just as it did before this 
> patch went in.

I understand, and that is good, but I'm talking from the POV of
someone who _wants_ to use this new feature, in order to make GDB
smaller.

Thanks.

  reply	other threads:[~2024-10-08 11:45 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
2024-10-07 19:58                       ` Guinevere Larsen
2024-10-08 11:44                         ` Eli Zaretskii [this message]
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=861q0qu8d7.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