Re: [PATCH] [GDB 18] gdb/configure: fix string quoting in AC_MSG_WARN and AC_MSG_ERROR

[Guinevere Larsen <guinevere@redhat.com>]

On 8/11/26 1:33 PM, Andrew Burgess wrote:
> Adding Guinevere to the CC list as the author of this feature.
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Andrew Burgess <aburgess@redhat.com>
>>> Cc: Eli Zaretskii <eliz@gnu.org>,
>>> 	Andrew Burgess <aburgess@redhat.com>
>>> Date: Tue, 11 Aug 2026 14:02:06 +0100
>>>
>>> If / when approve I plan to push this to both master and gdb-18-branch.
>> Thanks.  I have a question about this below.
>>
>>> Now when configuring with
>>> --enable-binary-file-formats='coff,xcoff,elf,macho' on a target that
>>> doesn't support Mach-O, e.g. GNU/Linux, the configure will stop like
>>> this:
>>>
>>>    checking for ELF support in BFD... yes
>>>    checking for library containing dlopen... (cached) none required
>>>    checking for Mach-O support in BFD... no
>>>    configure: error: Mach-O support was requested, but BFD does not support it
>>>    make: *** [Makefile:13461: configure-gdb] Error 1
>> Hmm... so building with Mach-O support on GNU/Linux and MS-Windows is
>> not possible at all?  I'm not sure I understand the "BFD does not
>> support it" part of the error message: shouldn't BFD that is compiled
>> as part of GDB be configured to support Mach-O when GDB is configured
>> with --enable-binary-file-formats='coff,xcoff,elf,macho'?  Or what am
>> I missing?
> My understand is that to get support for Mach-O you'll need to use
> --enable-targets=.... to add a suitable target in addition to the
> default (GNU/Linux or Windows depending on the build host).
>
> Doing this will, I believe, cause BFD to be built with support for that
> target.
>
> The --enable-binary-file-formats flag then controls the GDB side of
> things, you could choose to exclude macho support from GDB if you
> wished.
>
> I'm not sure the use case for doing that is super obvious, and I think
> that macho is probably a choice for a motivating use case.
(as a side-note the idea here is that, if a CVE is identified against 
the reader of a format that an OS doesn't support, the maintainers of 
GDB in that OS won't need to manage backports for that CVE, without 
leaving the system potentially vulnerable to that CVE).
>
> If we consider coff/xcoff, which on GNU/Linux we get "for free".  But
> supporting these in GDB means we have an increased surface area for
> bugs, all in code that many GNU/Linux distros don't care about.
>
> The motivation for the --enable-binary-file-formats flag was to be able
> to compile a GDB that runs on GNU/Linux and only supports ELF.
>
> Hopefully Guinevere will chip in and correct any mistakes I've made in
> the above explanation.

 From what I remember, and a cursory check in bfd/configure.ac, you're 
spot on

BFD decides which formats to support based on the targets that are being 
compiled, and that is ran well before --enabile-binary-file-formats has 
a chance to run, so the best that gdb's configure can do is detect that 
it's not available and warn you.

Note that before I introduced the feature, the format would just 
silently not be compiled in this example situation, and would always be 
compiled when a relevant target was added. You can verify that by 
compiling a previous release and looking for Mach-O related object 
files. So in the end, my only change was to notice when the user has 
specifically requested an impossible configuration, we loudly fail 
instead of silently ignoring the request.

>
> Thanks,
> Andrew
>

-- 
Cheers,
Guinevere Larsen
it/its
she/her (deprecated)