patch configure-check-function-sections.patch
What the developer wrote
Authored by Rusty Russell
patch configure-check-function-sections.patch
What changed, and why it matters
This commit changes the build configuration script so it tests whether the compiler supports a size-optimization feature (placing each function in its own section and removing unused ones during linking). It is a build-system hardening/optimization change, not a fix for an exploitable vulnerability. There is no indication in the commit that it addresses a security issue.
No security response required. Treat as a normal build-system improvement. If reviewing, verify the probe correctly handles compilers/linkers that reject these flags and that the cleanup trap covers all temporary files.
Security signals we found
Build-system hardening: enables linker garbage collection of unused functions when supported
No runtime code change
No mention of vulnerability, CVE, security bug, or researcher attribution in commit
Evidence from the diff
The patch adds a have_function_sections() probe to configure that compiles a tiny C snippet with -ffunction-sections -Wl,--gc-sections. If the probe succeeds, HAVE_FUNCTION_SECTIONS=1, LDFLAGS gets --gc-sections, and COPTFLAGS gets -ffunction-sections. The configurator binary is then built with those flags, and HAVE_FUNCTION_SECTIONS is exported to the build variables. The trap cleanup is also widened to remove the temporary probe files. This is a build-hardening/optimization change; it does not modify runtime behavior or fix a disclosed security flaw.
Changed components
configure build scriptInspect captured patch +23 / −2
diff --git a/configure b/configure
index f0cc855b..2f3d77cc 100755
--- a/configure
+++ b/configure
@@ -213,6 +213,17 @@ set_defaults()
RUST=${RUST:-$(default_rust_setting)}
}
+# Given CC and FLAGS do we support -ffunction-sections and --gc-sections?
+have_function_sections()
+{
+ # This gets removed automatically on exit!
+ TMPCFILE=$CONFIG_VAR_FILE.$$.c
+ TMPOBJFILE=$CONFIG_VAR_FILE.$$.o
+
+ echo "int foo(void); int foo(void) { return 0; }" > $TMPCFILE
+ $1 $2 -ffunction-sections -Wl,--gc-sections -c $TMPCFILE -o $TMPOBJFILE
+}
+
usage()
{
echo "Usage: ./configure [--reconfigure] [setting=value] [options]"
@@ -355,10 +366,19 @@ EOF
done
fi
+# We call this first, so we can make sure configurator runs with it as a sanity check!
+if have_function_sections $CC "${CWARNFLAGS-$BASE_WARNFLAGS} $CDEBUGFLAGS $COPTFLAGS"; then
+ HAVE_FUNCTION_SECTIONS=1
+ LDFLAGS="-Wl,--gc-sections"
+ COPTFLAGS="$COPTFLAGS -ffunction-sections"
+else
+ HAVE_FUNCTION_SECTIONS=0
+ LDFLAGS=
+fi
# We assume warning flags don't affect congfigurator that much!
echo -n "Compiling $CONFIGURATOR..."
-$CC ${CWARNFLAGS-$BASE_WARNFLAGS} $CDEBUGFLAGS $COPTFLAGS -o $CONFIGURATOR $CONFIGURATOR.c
+$CC ${CWARNFLAGS-$BASE_WARNFLAGS} $CDEBUGFLAGS $COPTFLAGS $LDFLAGS -o $CONFIGURATOR $CONFIGURATOR.c
echo "done"
if [ "$CLANG_COVERAGE" = "1" ]; then
@@ -406,7 +426,7 @@ if command -v "${PG_CONFIG}" >/dev/null; then
fi
# Clean up on exit.
-trap "rm -f $CONFIG_VAR_FILE.$$" 0
+trap "rm -f $CONFIG_VAR_FILE.$$*" 0
$CONFIGURATOR --extra-tests --autotools-style --var-file=$CONFIG_VAR_FILE.$$ --header-file=$CONFIG_HEADER.$$ --configurator-cc="$CONFIGURATOR_CC" --wrapper="$CONFIGURATOR_WRAPPER" "$CC" ${CWARNFLAGS-$BASE_WARNFLAGS} $CDEBUGFLAGS $COPTFLAGS $CSANFLAGS -I$CPATH -L$LIBRARY_PATH $SQLITE3_CFLAGS $SODIUM_CFLAGS $POSTGRES_INCLUDE <<EOF
@@ -619,6 +639,7 @@ add_var FUZZING "$FUZZING"
add_var RUST "$RUST"
add_var PYTHON "$PYTHON"
add_var SED "$SED"
+add_var HAVE_FUNCTION_SECTIONS "$HAVE_FUNCTION_SECTIONS"
# Hack to avoid sha256 name clash with libwally: will be fixed when that
# becomes a standalone shared lib.
Why this scored 18/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.