Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Simon Marchi <simark@simark.ca>
To: Guinevere Larsen <guinevere@redhat.com>, gdb-patches@sourceware.org
Cc: Eli Zaretskii <eliz@gnu.org>
Subject: Re: [PATCH v6] gdb, configure: Add disable-formats option for configure
Date: Tue, 5 Aug 2025 12:03:29 -0400	[thread overview]
Message-ID: <551458c7-bcb7-4643-91e4-9e01e0792425@simark.ca> (raw)
In-Reply-To: <20250707201657.972546-2-guinevere@redhat.com>

On 7/7/25 4:16 PM, Guinevere Larsen wrote:
> GDB has support for many binary file formats, some which might be very
> unlikely to be found in some situations (such as the XCOFF format in
> an x86 system). This commit introduces the option for a user to choose
> which formats GDB will support at build configuration time.
> 
> This is especially useful to avoid possible security concerns with
> readers that aren't expected to be used at all, as they are one of
> the simplest vectors for an attacker to try and hit GDB with.  This
> change can also reduce the size of the final binary, if that is a
> concern.
> 
> This commit adds a switch to the configure script allowing a user to
> only enable selected file formats, called --enable-binary-file-formats.
> The default behavior when the switch is omitted is to compile all file
> formats, keeping the original behavior of the script. At the time of
> this commit, the valid options for this option are: dbx, coff (which
> includes coff-pe), xcoff, mips, elf, macho and all. All is treated
> especially, activating all supported readers.
> 
> A few targets may require specific binary file format support, as they
> directly call functions defined by the file reader. Specifically,
> windows targets require coff support, and rs6000 aix and lynx178 targets
> require xcoff support. Considering that those formats are the main - or
> only - one available in those targets, I believe it makes sense to
> re-enable those readers. If that happens, the script will emit the
> following warning:
> 
>   FOO is required to support one or more requested targets. Adding it
> 
> Users aren't able to force the disabling of those formats, since GDB
> will not compile without those readers. Ideally we'd like to be able
> to disable even those formats, in case a user wants to build GDB only
> to examine remote files for example, but the current infrastructure
> for the file format readers doesn't allow us to do it.
> 
> Mach-O and elf support are also dependent on BFD support being compiled
> in.  In case one of those was requested and BFD does not support them,
> the following error is emitted:
> 
>     FOO was requested, but BFD does not support it.
> 
> Finally, this configure switch is also printed by the "show
> configuration" command in GDB.
> 
> Reviewed-By: Eli Zaretskii <eliz@gnu.org>
> ---
> 
> This is rebased on current master, there was a bit of a rebase conflict,
> but nothing complicated.

I think the git commit subject needs to be updated to reflect the new
option name.

> diff --git a/gdb/README b/gdb/README
> index eca4181c751..d45e6d37c4a 100644
> --- a/gdb/README
> +++ b/gdb/README
> @@ -417,6 +417,30 @@ more obscure GDB `configure' options are not listed here.
>       There is no convenient way to generate a list of all available
>       targets.
>  
> +`--enable-binary-file-formats=FORMAT,FORMAT,...'
> +`--enable-binary-file-formats=all'
> +    Configure GDB to only be be able to read selected file formats.
> +    The special value "all" causes all file formats to be compiled
> +    in, and is the the default behavior of the option.  This option
> +    is meant for advanced users who are sure of what they expect,
> +    if you are unsure which options you will need on your debugging
> +    sessions, we recommend that you not use this feature.  The
> +    accepted options are:

In the list below, a few instances of "two spaces after period".

> +      * coff: Main format on windows systems. This is required to
> +        compile with windows target support;

windows -> Windows

> +      * dbx (also known as a.out): is a legacy file format, this
> +        is recommended if you know you will be dealing with this
> +        file format;

Missing "This" at the beginning, to be like the other entries.

> +      * elf: Main format of linux systems. This is heavily
> +        recommended when compiling with linux support;

linux -> Linux

For consistency: in all entries except this one, the "This is heavily"
is just a phrase following a comma.  I would change this one to match.
In general if you can make the form consistent across items, it would be
nice.

> +      * macho: Main format on MacOS systems, this is heavily
> +        recommended when compiling for those targets;

MacOS -> macOS

> @@ -191,6 +191,15 @@ AS_HELP_STRING([--enable-targets=TARGETS], [alternative target configurations]),
>  	;;
>  esac])
>  
> +AC_ARG_ENABLE(binary_file_formats,
> +	      AS_HELP_STRING([--enable-binary-file-formats=FILE_FORMATS],

Question mostly for Eli, should the metavar use an underscore or dash
("FILE-FORMATS")?

> +			     [enable support for selected file formats (default 'all')]),

Since the list of valide values is finite and not too long, it might be
nice to list the possible values right there in the help message.

> +[case "${enableval}" in
> + yes | "") AC_MSG_ERROR(enable-formats option must specify file formats or 'all')

enable-formats -> enable-binary-file-formats

I think you are also missing a space before "yes".

> @@ -239,11 +248,20 @@ fi
>  TARGET_OBS=
>  all_targets=
>  HAVE_NATIVE_GCORE_TARGET=
> +# File formats that will be enabled based on the selected
> +# target(s).  These are chosen because they are required to
> +# compile one or more of the selected targets.
> +target_formats=
> +# If all targets were requested, this is all formats that should
> +# accompany them.  These are just the ones required for compilation
> +# to succeed, not the formats suggested based on targets.
> +all_target_formats="coff xcoff"

Please add empty lines before each comment above.

> @@ -1952,11 +1970,17 @@ fi
>  # Note that WIN32APILIBS is set by GDB_AC_COMMON.
>  WIN32LIBS="$WIN32LIBS $WIN32APILIBS"
>  
> +# Object files to be used when building with support for all file formats.
> +# This should not have elf or macho, as support for those formats depends
> +# on BFD enabling them as well.
> +all_binary_file_srcs="\$(dbx_SRCS) \$(mips_SRCS) \$(coff_SRCS) \$(xcoff_SRCS)"
> +
> +support_elf=no
>  # Add ELF support to GDB, but only if BFD includes ELF support.
>  GDB_AC_CHECK_BFD([for ELF support in BFD], gdb_cv_var_elf,
>                   [bfd_get_elf_phdr_upper_bound (NULL)], elf-bfd.h)
>  if test "$gdb_cv_var_elf" = yes; then
> -  CONFIG_OBS="$CONFIG_OBS elfread.o stap-probe.o dtrace-probe.o \
> +  CONFIG_OBS="$CONFIG_OBS stap-probe.o dtrace-probe.o \
>  		gcore-elf.o elf-none-tdep.o"

Does it make sense (or is it useful) to compile these other files (other
than elfread.o) if ELF support is not enabled?  Could we just list them
all in elf_SRCS so that they are not built if the user doesn't want ELF
support?  If you don't have an ELF reader.

If I understand correctly, "support_elf" means that BFD supports ELF,
not that GDB will support ELF, right?  If so, could you rename it to
"bfd_supports_elf"?

I also wouldn't mind if you renamed the conf var gdb_cv_var_elf to
something like gdb_cv_var_bfd_elf.

>    AC_DEFINE(HAVE_ELF, 1,
>  	    [Define if ELF support should be included.])
> @@ -1964,15 +1988,67 @@ if test "$gdb_cv_var_elf" = yes; then
>    if test "$plugins" = "yes"; then
>      AC_SEARCH_LIBS(dlopen, dl)
>    fi
> +  support_elf=yes
> +  all_binary_file_srcs="$all_binary_file_srcs \$(elf_SRCS)"
>  fi
>  
>  # Add macho support to GDB, but only if BFD includes it.
> +support_macho=no

Likewise for support_macho.

>  GDB_AC_CHECK_BFD([for Mach-O support in BFD], gdb_cv_var_macho,
>                   [bfd_mach_o_lookup_command (NULL, 0, NULL)], mach-o.h)
>  if test "$gdb_cv_var_macho" = yes; then
> -  CONFIG_OBS="$CONFIG_OBS machoread.o"
> +  support_macho=yes
> +  all_binary_file_srcs="$all_binary_file_srcs \$(macho_SRCS)"
> +fi
> +
> +FORMAT_SRCS=
> +
> +if test "$enable_binary_file_formats" != "all"; then
> +    # Formats that are required by some requested target(s).
> +    # Warn users that they are added, so no one is surprised.
> +    for req in $target_formats; do
> +	case ,$enable_binary_file_formats, in
> +	*,$req,*)
> +	    # Do nothing.
> +	    ;;

Does this work if $req is first or last in the list?

> +	*)
> +	    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
> +    done
> +
> +    AC_DEFINE_UNQUOTED(SUPPORTED_FORMATS, "$enable_binary_file_formats",
> +		       Which file formats were requested at configure time. )

I think that all variables related to this should be renamed to include
"binary file".  For instance, SUPPORTED_FORMATS ->
SUPPORTED_BINARY_FILE_FORMATS.  There are a few others in the configure
script or Makefile.

Also, "Which file formats" -> "Which binary file formats".

>  fi
>  
> +enable_binary_file_formats=$(echo $enable_binary_file_formats | sed 's/,/ /g')
> +
> +for format in $enable_binary_file_formats
> +do

Can you write a comment above that loop to indicate what it does?

> +    if test "$format" = "elf"; then
> +	if test "$support_elf" != "yes"; then
> +	    AC_MSG_ERROR("elf support was requested, but BFD does not support it.");
> +	fi
> +    elif test "$format" = "macho"; then
> +	if test "$support_macho" != "yes"; then
> +	    AC_MSG_ERROR("Mach-O support was requested, but BFD does not support it.");
> +	fi
> +    fi

Can you write the above as

    if test "$format" = "elf" && "$support_elf" != "yes"; then
	AC_MSG_ERROR("elf support was requested, but BFD does not support it.");
    fi

    if test "$format" = "macho" && "$support_macho" != "yes"; then
	AC_MSG_ERROR("Mach-O support was requested, but BFD does not support it.");
    fi

?  I find it a bit easier to read (less boilerplate).

Simon

  parent reply	other threads:[~2025-08-05 19:56 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-07 11:58 [PATCH v3] " Guinevere Larsen
2025-03-07 12:09 ` Eli Zaretskii
2025-03-07 12:49   ` Guinevere Larsen
2025-03-07 13:03     ` Eli Zaretskii
2025-03-27 20:21 ` [PING][PATCH " Guinevere Larsen
2025-04-03 17:35 ` [PATCH " Tom Tromey
2025-04-07 17:48   ` Guinevere Larsen
2025-04-07 19:23     ` Tom Tromey
2025-04-08 13:47 ` [PATCH v4] " Guinevere Larsen
2025-04-08 14:06   ` Andreas Schwab
2025-04-08 14:24     ` Guinevere Larsen
2025-04-08 14:44       ` Andreas Schwab
2025-05-26 17:11   ` [PATCH v5 1/1] " Guinevere Larsen
2025-07-07 20:16     ` [PATCH v6] " Guinevere Larsen
2025-07-31 18:42       ` [PING][PATCH " Guinevere Larsen
2025-08-05 16:03       ` Simon Marchi [this message]
2025-08-05 19:06         ` [PATCH " Eli Zaretskii
2025-08-05 19:36           ` Simon Marchi
2025-08-05 20:07         ` Guinevere Larsen
2025-08-06 13:53           ` Guinevere Larsen
2025-08-06 14:17       ` [PATCH v7 1/1] gdb, configure: Add enable-binary-file-format " Guinevere Larsen
2025-08-14 15:39         ` Tom Tromey
2025-08-14 16:23           ` Guinevere Larsen
2025-05-27 11:32 ` [PATCH v3] gdb, configure: Add disable-formats " Pedro Alves
2025-05-27 16:26   ` Guinevere Larsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=551458c7-bcb7-4643-91e4-9e01e0792425@simark.ca \
    --to=simark@simark.ca \
    --cc=eliz@gnu.org \
    --cc=gdb-patches@sourceware.org \
    --cc=guinevere@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox