Re: [PATCH] gdb, configure: Add disable-formats option for configure

[Eli Zaretskii <eliz@gnu.org>]

> From: Andrew Burgess <aburgess@redhat.com>
> Cc: gdb-patches@sourceware.org
> Date: Wed, 02 Oct 2024 14:25:05 +0100
> 
> Consider the base gdb package as shipped with Fedora Linux.  The
> `--target' is set to match the `--host', but in addition we pass
> `--enable-targets=' to cover a select few architectures running Linux.
> There's no Windows, Solaris, FreeBSD, AIX, or any other OS support built
> in which means the GDB will not be able to remote debug any of these
> targets in a meaningful way[1].  Fedora just doesn't want to commit to
> supporting debug for these targets, and this includes both OS and
> architecture choices.  And that's OK.  There are other packages which
> offer builds of GDB for specific other target, for example, there's a
> package which offers bare-metal AVR support, which is not something the
> base gdb package supports.
> 
> However, right now, despite only configuring to support Linux based
> targets, Fedora GDB still end up building in support for many different
> file formats that we just don't care about, and we'd really like a
> configure option that allows distributions to compile out the file
> formats that they don't want to support, just as, right now, Fedora
> chooses not to support debug on many different OSes.
> 
> I hope this helps a little.

It does, thanks.  What is still missing is the division of labor
between GDB and gdbserver in the remote-debugging scenario.  What I
thought was that gdbserver only needs to know some part of the
target's support, like starting and stopping the program, inserting
breakpoints, etc.  Whereas GDB needs to be able to read the debug
info, access and show the source and machine code, etc.  Is that true?
If so, then building GDB with support for reading debug info in
various formats will allow the user to connect to a gdbserver that
supports a specific target, even though GDB itself wasn't built with
support for that target (since GDB can connect and talk to a gdbserver
from a different build of GDB).  Am I wrong about this?

If I'm right, then there are two separate aspects to "target": on the
one side, the ability to start/stop executables, insert breakpoints
and watchpoints, etc., and OTOH the ability to read and process debug
info used by that target, implement frame unwinders, etc.  Are we
currently conflating these into a single notion of "target", and if
so, will the proposed changes include or exclude both parts of each
"target"?