[PATCH 0/3] Improve Makefile robustness and explicitness

[PATCH 0/3] Improve Makefile robustness and explicitness

[Wander Lairson Costa]

This patch series introduces several improvements to the Makefile to
enhance portability and clarity.

The first two patches add checks to conditionally use compiler flags
-mno-omit-leaf-frame-pointer and -fcf-protection, preventing build
failures on systems where they are not supported.

The final patch makes the test invocation explicit, so `make tests`
successfully runs.

Wander Lairson Costa (3):
  Makefile: Conditionally add -mno-omit-leaf-frame-pointer
  Makefile: Improve compiler flag detection for -fcf-protection
  Makefile: Explicitly run the 'test' target in the tests directory

 Makefile | 22 ++++++++++++++--------
 1 file changed, 14 insertions(+), 8 deletions(-)

-- 
2.51.1

[PATCH 1/3] Makefile: Conditionally add -mno-omit-leaf-frame-pointer

[Wander Lairson Costa]

The -mno-omit-leaf-frame-pointer option is not available on all
architectures (e.g., s390x) or with older compiler versions. To avoid
compilation errors on such systems, this change adds a check to ensure
the option is only used when the compiler supports it.

This approach is similar to the existing check for -fcf-protection.

Signed-off-by: Wander Lairson Costa <wander@redhat.com>
Cc: Derek Barbosa <debarbos@redhat.com>
Cc: John Kacur <jkacur@redhat.com>
Cc: Juri Lelli <juri.lelli@redhat.com>
Cc: Chunsheng Luo <luochunsheng@ustc.edu>
---
 Makefile | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index c19e0bd..d605e60 100644
--- a/Makefile
+++ b/Makefile
@@ -60,7 +60,13 @@ FOPTS	:=	-flto=auto -ffat-lto-objects -fexceptions -fstack-protector-strong \
 		-fasynchronous-unwind-tables -fstack-clash-protection -fno-omit-frame-pointer \
 		$(strip $(FCF_PROTECTION)) -fpie
 
-MOPTS   :=  	$(strip $(MTUNE)) $(strip $(M64)) -mno-omit-leaf-frame-pointer
+# Test if compiler supports -mno-omit-leaf-frame-pointer
+OMIT_LEAF_FP := $(shell echo 'int main(void){return 0;}' | \
+		$(CC) -x c -mno-omit-leaf-frame-pointer - \
+		-o /dev/null 2>/dev/null && \
+		echo '-mno-omit-leaf-frame-pointer')
+
+MOPTS   :=  	$(strip $(MTUNE)) $(strip $(M64)) $(strip $(OMIT_LEAF_FP))
 
 WOPTS	:= 	-Wall -Werror=format-security
 
-- 
2.51.1

[PATCH 2/3] Makefile: Improve compiler flag detection for -fcf-protection

[Wander Lairson Costa]

The previous method of detecting support for -fcf-protection relied on
a minimum GCC version check, which was not always accurate and could
fail on different architectures or compiler toolchains.

This commit replaces the version check with a more robust method that
directly tests if the compiler supports the -fcf-protection flag. This
ensures better portability and avoids compilation errors on systems
where the flag is not available.

This change mirrors the recently added detection logic for the
-mno-omit-leaf-frame-pointer flag.

Signed-off-by: Wander Lairson Costa <wander@redhat.com>
Cc: Derek Barbosa <debarbos@redhat.com>
Cc: John Kacur <jkacur@redhat.com>
Cc: Juri Lelli <juri.lelli@redhat.com>
Cc: Chunsheng Luo <luochunsheng@ustc.edu>
---
 Makefile | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/Makefile b/Makefile
index d605e60..bc82858 100644
--- a/Makefile
+++ b/Makefile
@@ -20,17 +20,14 @@ IS_MINVER := $(intcmp $(GCC_VER), $(MIN_GCC_VER), false, true, true)
 $(info IS_MINVER=$(IS_MINVER))
 
 USE_BPF := 1
-FCF_PROTECTION := -fcf-protection
 MTUNE	:= -mtune=generic
 M64	:= -m64
 
 ifeq ($(ARCH),aarch64)
-FCF_PROTECTION := "-fcf-protection=none"
 M64	:=
 endif
 ifeq ($(ARCH),i686)
 USE_BPF := 0
-FCF_PROTECTION := "-fcf-protection=branch"
 endif
 ifeq ($(ARCH),s390x)
 MTUNE := -mtune=z13
@@ -43,9 +40,12 @@ ifeq ($(ARCH),powerpc)
 USE_BPF := 0
 MTUNE := -mtune=powerpc
 endif
-ifeq ($(strip $(IS_MINVER)), false)
-FCF_PROTECTION := 
-endif
+
+# Test if compiler supports -fcf-protection
+FCF_PROTECTION := $(shell echo 'int main(void){return 0;}' | \
+		$(CC) -x c -fcf-protection - \
+		-o /dev/null 2>/dev/null && \
+		echo '-fcf-protection')
 
 
 $(info USE_BPF=$(USE_BPF))
-- 
2.51.1

[PATCH 3/3] Makefile: Explicitly run the 'test' target in the tests directory

[Wander Lairson Costa]

The 'tests' target in the main Makefile was invoking 'make' in the
'tests' subdirectory without specifying a target. This relied on the
default target in the tests/Makefile, which is not explicit.

This commit adds the 'test' target to the make command, making the
build process clearer and more robust.

Signed-off-by: Wander Lairson Costa <wander@redhat.com>
Cc: Derek Barbosa <debarbos@redhat.com>
Cc: John Kacur <jkacur@redhat.com>
Cc: Juri Lelli <juri.lelli@redhat.com>
Cc: Chunsheng Luo <luochunsheng@ustc.edu>
---
 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index bc82858..7accd81 100644
--- a/Makefile
+++ b/Makefile
@@ -182,7 +182,7 @@ static: $(OBJ)
 	$(CC) -o stalld-static $(LDFLAGS) --static $(OBJ) $(LIBS)
 
 tests:
-	make -C tests VERSION=$(VERSION) CFLAGS="$(CFLAGS)" LDFLAGS="$(LDFLAGS)"
+	make -C tests VERSION=$(VERSION) CFLAGS="$(CFLAGS)" LDFLAGS="$(LDFLAGS)" test
 
 .PHONY: install
 install: stalld
-- 
2.51.1

Re: [PATCH 2/3] Makefile: Improve compiler flag detection for -fcf-protection

[Derek Barbosa]

On Fri, Nov 07, 2025 at 01:17:27PM -0300, Wander Lairson Costa wrote:
> The previous method of detecting support for -fcf-protection relied on
> a minimum GCC version check, which was not always accurate and could
> fail on different architectures or compiler toolchains.
> 
> This commit replaces the version check with a more robust method that
> directly tests if the compiler supports the -fcf-protection flag. This
> ensures better portability and avoids compilation errors on systems
> where the flag is not available.
> 
> This change mirrors the recently added detection logic for the
> -mno-omit-leaf-frame-pointer flag.
> 
> Signed-off-by: Wander Lairson Costa <wander@redhat.com>
> Cc: Derek Barbosa <debarbos@redhat.com>
> Cc: John Kacur <jkacur@redhat.com>
> Cc: Juri Lelli <juri.lelli@redhat.com>
> Cc: Chunsheng Luo <luochunsheng@ustc.edu>
> ---
>  Makefile | 12 ++++++------
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/Makefile b/Makefile
> index d605e60..bc82858 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -20,17 +20,14 @@ IS_MINVER := $(intcmp $(GCC_VER), $(MIN_GCC_VER), false, true, true)
>  $(info IS_MINVER=$(IS_MINVER))
>  
>  USE_BPF := 1
> -FCF_PROTECTION := -fcf-protection
>  MTUNE	:= -mtune=generic
>  M64	:= -m64
>  
>  ifeq ($(ARCH),aarch64)
> -FCF_PROTECTION := "-fcf-protection=none"
>  M64	:=
>  endif
>  ifeq ($(ARCH),i686)
>  USE_BPF := 0
> -FCF_PROTECTION := "-fcf-protection=branch"
>  endif
>  ifeq ($(ARCH),s390x)
>  MTUNE := -mtune=z13
> @@ -43,9 +40,12 @@ ifeq ($(ARCH),powerpc)
>  USE_BPF := 0
>  MTUNE := -mtune=powerpc
>  endif
> -ifeq ($(strip $(IS_MINVER)), false)
> -FCF_PROTECTION := 
> -endif
> +
> +# Test if compiler supports -fcf-protection
> +FCF_PROTECTION := $(shell echo 'int main(void){return 0;}' | \
> +		$(CC) -x c -fcf-protection - \
> +		-o /dev/null 2>/dev/null && \
> +		echo '-fcf-protection')
>  

If we're no longer guarding FCF_PROTECTION on IS_MINVER, I think we can just
remove that intcmp check all together.

Otherwise this LGTM.

>  
>  $(info USE_BPF=$(USE_BPF))
> -- 
> 2.51.1
> 
-- 
Derek <debarbos@redhat.com>

Re: [PATCH 0/3] Improve Makefile robustness and explicitness

[Sebastian Andrzej Siewior]

On 2025-11-07 13:17:25 [-0300], Wander Lairson Costa wrote:
> The first two patches add checks to conditionally use compiler flags
> -mno-omit-leaf-frame-pointer and -fcf-protection, preventing build
> failures on systems where they are not supported.

I don't know what this part of but shouldn't the Makefile just consume
what the buildsystem provided and not randomly strip CFLAGS?

Sebastian

Re: [PATCH 0/3] Improve Makefile robustness and explicitness

[Derek Barbosa]

On Tue, Nov 11, 2025 at 03:50:20PM +0100, Sebastian Andrzej Siewior wrote:
> On 2025-11-07 13:17:25 [-0300], Wander Lairson Costa wrote:
> > The first two patches add checks to conditionally use compiler flags
> > -mno-omit-leaf-frame-pointer and -fcf-protection, preventing build
> > failures on systems where they are not supported.
> 
> I don't know what this part of but shouldn't the Makefile just consume
> what the buildsystem provided and not randomly strip CFLAGS?
> 
> Sebastian
> 

Hey Sebastian,

Part of the changes were to keep in line with what Daniel had in the makefile
originally, and just doing some hacks to ensure that these flags are
conditionally included based on arch support.

In the case of -fcf-protection, Clark and I noticed that if a particular host
system was using, say, the sched debug file as a parsing logic "backend" by
specifying it in the command line, it was most likely because the system does
not have BTF support enabled.

We were particularly worried about much older systems with older compiler
versions, which would prevent them from compiling stalld from source if they
desired to use this legacy interface.

Not sure if this answers your question at all. Sorry for the rant.

-- 
Derek <debarbos@redhat.com>

Re: [PATCH 0/3] Improve Makefile robustness and explicitness

[Sebastian Andrzej Siewior]

On 2025-11-11 10:35:58 [-0500], Derek Barbosa wrote:
> Hey Sebastian,
Hi Derek,

> Part of the changes were to keep in line with what Daniel had in the makefile
> originally, and just doing some hacks to ensure that these flags are
> conditionally included based on arch support.
> 
> In the case of -fcf-protection, Clark and I noticed that if a particular host
> system was using, say, the sched debug file as a parsing logic "backend" by
> specifying it in the command line, it was most likely because the system does
> not have BTF support enabled.
> 
> We were particularly worried about much older systems with older compiler
> versions, which would prevent them from compiling stalld from source if they
> desired to use this legacy interface.
> 
> Not sure if this answers your question at all. Sorry for the rant.

I understand. I'm just trying to say my two words here what a distro/
builder should do here and the piece of software.

On Debian, the build flags start with the "dpkg-buildflags" command
which the CFLAGS for instance (among other things). So this is might
look as follows
| CFLAGS=-g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/build/pkg=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection

on amd64. Should, for instance, -fcf-protection not be supported on
s390x it is dpkg-buildflags's job not to pass those on s390x. There
features which are enabled conditionally because not all architectures
enable/ provide them at the same time.

If the package maintainer decides to add a certain flag, such as
-fcf-protection, despite not working on all architectures then he can
keep the pieces.
In my opinion the package should not fiddle with what the upper layer
(build system) specified/ requested. It may have a default set of flags
(such as -O2 -g) which will be overwritten once the user supplied
something. The default set should not be something that is not required
and is not always provided by the compiler specified as minimum.

Sebastian

Re: [PATCH 0/3] Improve Makefile robustness and explicitness

[Derek Barbosa]

On Tue, Nov 11, 2025 at 04:50:32PM +0100, Sebastian Andrzej Siewior wrote:
> If the package maintainer decides to add a certain flag, such as
> -fcf-protection, despite not working on all architectures then he can
> keep the pieces.

Tagging Crystal as she has weighed in on this topic in previous threads.

> In my opinion the package should not fiddle with what the upper layer
> (build system) specified/ requested. It may have a default set of flags
> (such as -O2 -g) which will be overwritten once the user supplied
> something.

Agreed. We've already stripped out a lot of the RHEL-styled options of the
makefile with this logic.

Wander & Clark, any thoughts?

> The default set should not be something that is not required
> and is not always provided by the compiler specified as minimum.

With this tidbit in mind, what else do you propose we strip out and leave to the
packagers? Is it worth retaining some of the debug & hardening flags, and
leaving the rest to them?

Cheers,

> 
> Sebastian
> 

-- 
Derek <debarbos@redhat.com>

Re: [PATCH 0/3] Improve Makefile robustness and explicitness

[Sebastian Andrzej Siewior]

On 2025-11-11 11:29:17 [-0500], Derek Barbosa wrote:
> > The default set should not be something that is not required
> > and is not always provided by the compiler specified as minimum.
> 
> With this tidbit in mind, what else do you propose we strip out and leave to the
> packagers? Is it worth retaining some of the debug & hardening flags, and
> leaving the rest to them?

I don't know what this is part of, I just seen the Makefile bits. I
don't worry if you keep some debug flags and or hardening which are
universal. Just don't set anything special which you might need to
filter out later… Or add later on additional bits once "new" debug or
hardening switches become a thing because this is IMHO not the place for
it. It should be passed by the upper layer.

A simple example would be using cmake: Set the .c files you want to
compile, set the libs you need as dependency and are done. cmake has a
profile for debug, release and release+debug. The build environment can
set custom flags. This is what I see is mostly done.

> Cheers,

Sebastian

Re: [PATCH 0/3] Improve Makefile robustness and explicitness

[Wander Lairson Costa]

On Tue, Nov 11, 2025 at 1:29 PM Derek Barbosa <debarbos@redhat.com> wrote:
>
> On Tue, Nov 11, 2025 at 04:50:32PM +0100, Sebastian Andrzej Siewior wrote:
> > If the package maintainer decides to add a certain flag, such as
> > -fcf-protection, despite not working on all architectures then he can
> > keep the pieces.
>
> Tagging Crystal as she has weighed in on this topic in previous threads.
>
> > In my opinion the package should not fiddle with what the upper layer
> > (build system) specified/ requested. It may have a default set of flags
> > (such as -O2 -g) which will be overwritten once the user supplied
> > something.
>
> Agreed. We've already stripped out a lot of the RHEL-styled options of the
> makefile with this logic.
>
> Wander & Clark, any thoughts?
>

Some time ago I spoke with Clark about how we are setting the CFLAGS
and not allowing the builder to create additional flags.
Furthermore, I found all those architectural dependent ifs strange.
More recently, we've talked about adding a more robust build
system to stalld, to avoid the hacks, we are adding to the Makefile as
well as complying with standard Linux packages.

> > The default set should not be something that is not required
> > and is not always provided by the compiler specified as minimum.
>
> With this tidbit in mind, what else do you propose we strip out and leave to the
> packagers? Is it worth retaining some of the debug & hardening flags, and
> leaving the rest to them?
>
> Cheers,
>
> >
> > Sebastian
> >
>
> --
> Derek <debarbos@redhat.com>
>