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

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

[Andrew Burgess]

If / when approve I plan to push this to both master and gdb-18-branch.

Thanks,
Andrew

---

Eli pointed out an issue with --enable-binary-file-formats, when GDB
is built with --enable-binary-file-formats='coff,xcoff,elf,macho' on a
target that doesn't support Mach-O, then GDB would configure
correctly, but then fail to build with an error like:

     CXXLD  gdb.exe
     d:/usr/bin/../lib/gcc/mingw32/9.2.0/../../../../mingw32/bin/ld.exe:
             machoread.o: in function `macho_check_dsym':
     d:\gnu\gdb-18.0.90\gdb/machoread.c:738:(.text+0xb16):
             undefined reference to `bfd_mach_o_lookup_command'
     d:/usr/bin/../lib/gcc/mingw32/9.2.0/../../../../mingw32/bin/ld.exe:
             d:\gnu\gdb-18.0.90\gdb/machoread.c:757:(.text+0xbe6):
                     undefined reference to `bfd_mach_o_lookup_command'
     collect2.exe: error: ld returned 1 exit status

See the original report here:

  https://inbox.sourceware.org/gdb-patches/865x1j1z61.fsf@gnu.org

It turns out the problem was incorrect quoting in an AC_MSG_ERROR call
within the configure script.  The current code is structured like
this:

  if CONDITION_1; then
    AC_MSG_ERROR("some message, some more message")
  elif CONDITION_2; then
    AC_MSG_ERROR("some message, some more message")
  fi

As "..." is not recognized as quoting by m4, the comma inside is
interpreted as an m4 argument separator, so 'some more message"'
including the trailing quote becomes the exit status and '"some
message' becomes the error message.

Configure understands to quote the '"' in the error message, but the
'"' in the exit status is not quoted, which leaves an unbalanced quote
in the configure script.

Luckily the second AC_MSG_ERROR line also has the same problem, which
adds a second unbalanced '"' into the configure script, which closes
the string started by the first unbalanced quote.

The string formed by these two unbalanced quotes just happens to
include the entire CONDITION_2 `if` check.

Fix this by replacing the use of '"..."' with '[...]' instead.

This issue was introduced in commit:

  commit 809c1abc19d487daeed75842da867ce633159210
  Date:   Wed Aug 21 11:10:50 2024 -0300

    gdb, configure: Add enable-binary-file-format option for configure

As well as the two AC_MSG_ERROR calls the above commit introduced an
incorrectly quoted AC_MSG_WARN call, I've fixed that too.

The above commit also added an unnecessary ';' at the end of the two
AC_MSG_ERROR lines, I've removed them in this commit.

While reviewing the above commit I spotted a couple of issues with the
error messages themselves.  First 'elf' should be 'ELF' when talking
about the file format, so I fixed that.  And second, AC_MSG_ERROR
calls normally don't have a trailing period, so I removed these from
the error messages added by 809c1abc19d487da.

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

Finally, during a final review of this patch I spotted another place
in our configure script where we were not quoting the argument to
AC_MSG_WARN correctly.  In this case the error was added in commit
e76c5d173bbf7137.  The problem line is:

  AC_MSG_WARN(disabling guile support, $GUILD fails compiling for $host)

As AC_MSG_WARN expects only a single argument, everything after the
comma will be discarded.  Quote the string with '[...]' to ensure the
full string is printed.
---
 gdb/configure    | 12 ++++++------
 gdb/configure.ac |  8 ++++----
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/gdb/configure b/gdb/configure
index 303d6ea011c..633004d3f70 100755
--- a/gdb/configure
+++ b/gdb/configure
@@ -29315,8 +29315,8 @@ $as_echo "$ac_cv_guild_ok" >&6; }
 
     if test "$ac_cv_guild_ok" = no; then
     have_libguile=no
-    { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: disabling guile support" >&5
-$as_echo "$as_me: WARNING: disabling guile support" >&2;}
+    { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: disabling guile support, $GUILD fails compiling for $host" >&5
+$as_echo "$as_me: WARNING: disabling guile support, $GUILD fails compiling for $host" >&2;}
   fi
 fi
 
@@ -32080,8 +32080,8 @@ if test "$enable_binary_file_formats" != "all"; then
 	    # Do nothing.
 	    ;;
 	*)
-	    { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: \"$req is required to support one or more requested targets.  Adding it\"" >&5
-$as_echo "$as_me: WARNING: \"$req is required to support one or more requested targets.  Adding it\"" >&2;}
+	    { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: $req is required to support one or more requested targets.  Adding it" >&5
+$as_echo "$as_me: WARNING: $req is required to support one or more requested targets.  Adding it" >&2;}
 	    enable_binary_file_formats="${enable_binary_file_formats},$req"
 	    ;;
 	esac
@@ -32101,9 +32101,9 @@ enable_binary_file_formats=$(echo $enable_binary_file_formats | sed 's/,/ /g')
 for format in $enable_binary_file_formats
 do
     if test "$format" = "elf" && test "$bfd_supports_elf" != "yes"; then
-	    as_fn_error but BFD does not support it." "\"elf support was requested" "$LINENO" 5;
+	    as_fn_error $? "ELF support was requested, but BFD does not support it" "$LINENO" 5
     elif test "$format" = "macho" && test "$bfd_supports_macho" != "yes"; then
-	    as_fn_error but BFD does not support it." "\"Mach-O support was requested" "$LINENO" 5;
+	    as_fn_error $? "Mach-O support was requested, but BFD does not support it" "$LINENO" 5
     fi
 
     if test "$format" = "all"; then
diff --git a/gdb/configure.ac b/gdb/configure.ac
index e55a733fba7..943b2218a41 100644
--- a/gdb/configure.ac
+++ b/gdb/configure.ac
@@ -1298,7 +1298,7 @@ if test "${have_libguile}" != no; then
   dnl If not, disable guile support.
   if test "$ac_cv_guild_ok" = no; then
     have_libguile=no
-    AC_MSG_WARN(disabling guile support, $GUILD fails compiling for $host)
+    AC_MSG_WARN([disabling guile support, $GUILD fails compiling for $host])
   fi
 fi
 
@@ -2080,7 +2080,7 @@ if test "$enable_binary_file_formats" != "all"; then
 	    # Do nothing.
 	    ;;
 	*)
-	    AC_MSG_WARN("$req is required to support one or more requested targets.  Adding it")
+	    AC_MSG_WARN([$req is required to support one or more requested targets.  Adding it])
 	    enable_binary_file_formats="${enable_binary_file_formats},$req"
 	    ;;
 	esac
@@ -2097,9 +2097,9 @@ enable_binary_file_formats=$(echo $enable_binary_file_formats | sed 's/,/ /g')
 for format in $enable_binary_file_formats
 do
     if test "$format" = "elf" && test "$bfd_supports_elf" != "yes"; then
-	    AC_MSG_ERROR("elf support was requested, but BFD does not support it.");
+	    AC_MSG_ERROR([ELF support was requested, but BFD does not support it])
     elif test "$format" = "macho" && test "$bfd_supports_macho" != "yes"; then
-	    AC_MSG_ERROR("Mach-O support was requested, but BFD does not support it.");
+	    AC_MSG_ERROR([Mach-O support was requested, but BFD does not support it])
     fi
 
     if test "$format" = "all"; then

base-commit: a80fede20bc1330eca5e419392c6595bb3a6ac1d
-- 
2.25.4

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

[Eli Zaretskii]

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

Thanks.

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

[Andrew Burgess]

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.

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.

Thanks,
Andrew

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

[Guinevere Larsen]

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)

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

[Tom Tromey]

>>>>> "Andrew" == Andrew Burgess <aburgess@redhat.com> writes:

Andrew> If / when approve I plan to push this to both master and gdb-18-branch.

FWIW I think the patch is correct.
Approved-By: Tom Tromey <tom@tromey.com>

Tom

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

[Andrew Burgess]

Tom Tromey <tom@tromey.com> writes:

>>>>>> "Andrew" == Andrew Burgess <aburgess@redhat.com> writes:
>
> Andrew> If / when approve I plan to push this to both master and gdb-18-branch.
>
> FWIW I think the patch is correct.
> Approved-By: Tom Tromey <tom@tromey.com>

I've pushed to both master and gdb-18-branch.

I don't know if Eli will have any follow up on this feature, but even if
wider changes to this feature are made, we might as well fix the current
implementation.

Thanks,
Andrew

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

[Eli Zaretskii]

> From: Andrew Burgess <aburgess@redhat.com>
> Cc: gdb-patches@sourceware.org, Eli Zaretskii <eliz@gnu.org>
> Date: Thu, 13 Aug 2026 10:08:11 +0100
> 
> Tom Tromey <tom@tromey.com> writes:
> 
> >>>>>> "Andrew" == Andrew Burgess <aburgess@redhat.com> writes:
> >
> > Andrew> If / when approve I plan to push this to both master and gdb-18-branch.
> >
> > FWIW I think the patch is correct.
> > Approved-By: Tom Tromey <tom@tromey.com>
> 
> I've pushed to both master and gdb-18-branch.
> 
> I don't know if Eli will have any follow up on this feature, but even if
> wider changes to this feature are made, we might as well fix the current
> implementation.

Thanks.  If there will be another pretest, I will certainly provide
feedback.  But the change looks okay to me even without trying, since
you tested it yourself.  I was not aware that BFD had its own ideas
about what can and cannot be built, and was previously silently
omitting binary formats it couldn't support.  TIL.