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

[Andrew Burgess <aburgess@redhat.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> 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?

Yes.

gdbserver supports far fewer target OSes than GDB itself, as far as I
can tell it's Linux, netbsd, or Windows.

Unlike GDB, gdbserver only every supports a single target.  This makes
sense as gdbserver only ever controls native processes running on the
same machine as gdbserver itself.  This is enforced at configure time,
if we configure the binutils-gdb tree with --target not equal to --host
then the gdbserver directory will be disabled, and we don't even attempt
to build gdbserver.

GDB splits target support into *-tdep.c and *-nat.c files.  The *-nat.c
file is for lower level, native target stuff, e.g. how do I create a new
process, how do I read the registers.

Then the *-tdep.c files are for higher level target specific stuff,
e.g. setting up platform specific types, registering special frame
unwinders, signal handling details, etc.

gdbserver only needs to include the lower level knowledge, the
equivalent of the *-nat.c files, though on the gdbserver side these
files are called *-low.cc.  Some code is shared between GDB and
gdbserver in this area, but not everything.  This can, and should be
improved.

But the high level logic, the *-tdep.c files, only live in GDB.  When a
target is compiled into GDB this causes the tdep files to get built in.

Which nat files we build in depends on the --host configure option, that
is, where is GDB (the program) going to run.

> 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?

The problem is that reading the file is only one part of the process.
The target specific tdep file adds higher level knowledge on top of the
file contents.

I dug out an old windows machine and setup the following debug
environment: on the windows machine I built gdbserver for
x86_64-w64-mingw32, then on an x86-64 Linux machine I built GDB only
with support for x86_64-redhat-linux.  The source I was building from
didn't include Gwen's patch, so all file formats are usable.

GDB is able to connect to gdbserver, and can read the executable and
libraries, and can extract the symbols.  However, GDB gets the addresses
for all symbols wrong.

The reason for this can be found in windows_init_abi_common where we
call set_gdbarch_so_ops.  This call registers some callbacks that are
used whenever GDB opens a library or executable.  These callbacks can do
things like fix up the objfile section addresses, which is exactly
what's being done in this case.  As the windows_init_abi_common is in
windows-tdep.c, when this file is not compiled in, GDB doesn't really
"understand" the executable file within a Windows context, and so the
sections offsets are left as 0, and GDB gets all the symbol addresses
wrong.

So, I can disassemble instructions using an address and length,
e.g. 'x/10i ADDRESS', or place breakpoints by address 'b *ADDRESS', but
I can't do anything that relies on symbols, e.g. 'b main', or
'disassemble main'.

In addition GDB isn't going to be able to backtrace correctly, skip
function prologues, or any of that other good stuff.

Out of interest, I also tried building GDB with only Linux support, and,
using Gwen's patch, with only ELF file format support.  My thinking was
that, if previously GDB could read the file, but couldn't actually do
anything useful with the symbols, then maybe we're no worse off if GDB
just can't read the file at all...

...unfortunately, GDB segfault.  I'll report this to Gwen separately.
But in theory, we'd probably be better off if GDB didn't read the
symbols from the file, given that GDB can't then figure out the correct
addresses.

> 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"?

I agree with you about "target" having two components, the lower level
stuff, and the higher level stuff.

File format support, being able to read from file, only (I think)
impacts higher level functionality.  But just reading the file isn't (I
claim) enough, we need the higher level functionality in order to really
"understand" the file contents.

My claim then is that being able to remove the file format support will
actually make the GDB slightly better (in some cases) as GDB will no
longer be able to read a file which it is then unable to correctly
process the contents of.

Thanks,
Andrew