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

[Andrew Burgess <aburgess@redhat.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Thu, 26 Sep 2024 18:03:05 -0300
>> Cc: gdb-patches@sourceware.org
>> From: Guinevere Larsen <guinevere@redhat.com>
>> 
>> > My point was that the manual doesn't clarify these issues.  It left me
>> > confused.
>> >
>> >>> Maybe I'm confused, but if I am, it means we lack some important
>> >>> information in the manual which would clarify this.
>> >> Maybe more clarity would be helpful, but I don't think these issues have
>> >> to do with my patch itself, so I think this should be further
>> >> improvement for documentation rather than having to fix it in this patch.
>> > You may be right, but without clarifying this whole issue I cannot
>> > decide whether your additions about this are okay or not.  So I think
>> > we have no choice but to clarify those other aspects together with
>> > this review, even if just in principle.
>> I hope I clarified enough in this email to allow you to judge my changes 
>> on their own, and a later unrelated patch can fill in the missing 
>> information, since the changes really aren't related to enable-targets 
>> and it was my mistake to parse them there instead of just seeing which 
>> tdep files are compiled in and need a file format.
>

Hi Eli,

I was catching up on this thread and though I could help by expanding
the docs on the --enable-targets and --target flags, but I was confused
by one of your questions below...

> Unfortunately, I'm still in the dark here.  I'd appreciate if you or
> someone else who understands the way we deal with targets in all the 3
> scenarios -- native debugging, cross-debugging, remote debugging --

In my mind cross-debugging IS remote debugging, I don't understand what
the distinction would be.

Let's build up some examples to work through why I hold the above
belief.  What follows are GDB configure lines and then a description of
what capabilities I think that GDB would have.  This ignores the work
Gwen has done, as you say, lets get the docs for --target and
--enable-targets sorted first, then Gwen's work can sit on top of that:

(1)  ./configure

     This GDB will be able to run on the build host and will support
     debugging the build host only.  This GDB will support remote
     debugging, but only to targets that are the same as the build
     host, i.e. same architecture and same OS.

(2) ./configure --target=<1>

    Assuming that <1> doesn't match the build host, then this GDB will
    be able to run on the build host but will not be able to debug
    native processes.  In fact the native target support will not even
    be compiled into GDB.  This GDB will be able to remote debug
    inferior's running on a remote host that matches <1>.

(3) ./configure --host=<1>

    Throwing this one in just for completion.  Assuming that <1> doesn't
    match my local build machine, this is going to cross-build GDB to
    run on a <1> host machine.  GDB will be able to debug native
    processes on the <1> host, and GDB will also be able to remote debug
    processes on machines that are also of <1> type.

(4) ./configure --host=<1> --target=<2>

    Assuming that <1> does not match my local build machine, and that
    <2> doesn't match <1>, this is going to cross build GDB to run on
    machines of type <1>, and GDB will only be able to remote debug
    targets of type <2>.  As with case (1) native target support isn't
    going to be built into GDB.

What you'll notice in all of the above is that --target only allows a
single target type to be specified.  If we want GDB to support multiple
targets then --enable-targets can be used.  This option takes a list of
targets which are built into GDB in addition to the --target value.  So:

 (5) ./configure --enable-targets=<1>,<2>,<3>

     Without an explicit --target option this is similar to case (1)
     above.  GDB will run on the build host and can debug either
     natively, or remotely, inferiors running on machines that are the
     same as the build host.  In addition, assuming <1>, <2>, and <3>
     are all different from the build host, GDB will be able to remote
     debug targets matching <1>, <2>, and <3>.

     Of course, we are free to use `--enable-targets=all' which adds
     support for all known targets to GDB.  In this case the build host
     type is effectively passed twice, once implicitly in the `--target'
     option, and then again as a member of `--enable-targets=all', but
     that's OK, the configure scripts can cope with this, and we just
     build everything into GDB.

One important detail is that there is no real difference from specifying
a target via --target vs via --enable-targets.  Consider this case:

 (6) ./configure --host=<2> --target=<1> --enable-targets=<2>

     This GDB will run on <2> and will be able to debug native processes
     on <2>.  In addition GDB will be able to remote debug <1> and <2>.
     This is equivalent to:

 (7) ./configure --host=<2> --enable-targets=<1>

     Without an explicit `--target' option the configure script assumes
     that the target should match the host, then we add the ability to
     also remote debug <1>.

> could explain how this stuff works (and perhaps how it should work
> ideally, if what we have is not ideal/correct), and then we could take
> it from there.

This all seems OK to me.  If you agree then I'm happy to try and tighten
up the docs a little to (hopefully) better explain things.

> We could, of course, just go with your changes disregarding these
> larger issues, but I think clarifying them will also help us
> understand better this new feature and make sure it is designed and
> implemented correctly.

I think Gwen's changes are broadly fine (I have some minor nits), but I
agree with you, Eli, that we should try to get the docs into a state
where this makes sense.  I know you have a huge amount of experience
with configuring / building GNU software, so if you can't read the docs
and understand this, then it feels like a less experienced user is going
to be even more confused.

> OTOH, if I'm the only one who doesn't fully understand this stuff, and
> everyone else agrees with the suggested changes as they are, feel free
> to ignore me.

I certainly don't think you should be ignored, but I'd like to give my
attempt at explaining the motivation for this work, and why I think this
is OK (once it's documented well enough).

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.

If you can give your thoughts on what I wrote about --target and
--enable-targets= above, then I'll try to draft a patch that improves
the docs in this area, then Gwen can update on top of that, which
hopefully will bring some clarity.

Thanks,
Andrew

[1] In some cases it might be possible to connect to a remote target and
perform basic (address based) debugging even if support for the target
OS is not available in GDB.  GDB would need to have support for the
target architecture compiled in (which is not always the case), and GDB
still might struggle to access inferior state in some cases.  That
anything works in this case is, I feel, more by luck than design, so I
don't really consider this "working".