“missing .note.GNU-stack section implies executable stack” when building OpenBLAS #5313

loss-and-quick · 2025-06-18T00:06:14Z

loss-and-quick
Jun 18, 2025

When building OpenBLAS (version 0.3.29) in an environment (Buildroot) without proper .note.GNU-stack handling, the resulting libopenblas.so.0 is marked as requiring an executable stack. As a result, Python fails to load NumPy (which links against OpenBLAS) with:

ImportError: libopenblas.so.0: cannot enable executable stack as shared object requires: Invalid argument

The root cause is missing or incorrect .note.GNU-stack in one or more object files (or lack of appropriate assembler/linker flags) during OpenBLAS build, causing the final library to be marked as needing exec-stack.

Environment:

OpenBLAS version: 8795fc7
Build system: Buildroot (2025.02.3) cross-compile for ARM (cortex-A7)
Toolchain: GCC 14.2.1.20250322 on NixOS
Target OS: Linux.
Python/NumPy version: Python 3.x, NumPy linked against the built OpenBLAS library.

Steps to Reproduce:

Configure Buildroot to build OpenBLAS for target (ARM).
Build OpenBLAS without ensuring .note.GNU-stack directives or -Wa,--noexecstack / -Wl,-z,noexecstack flags.
Install resulting libopenblas.so.0 into the target filesystem or host sysroot.
Attempt to run Python (on target or via QEMU) and import numpy.

Observe error:

ImportError: libopenblas.so.0: cannot enable executable stack as shared object requires: Invalid argument

Observed Behavior:

The build emits warnings like:

warning: missing .note.GNU-stack section implies executable stack
NOTE: This behaviour is deprecated and will be removed in a future version of the linker

or may not emit warnings if suppressed, but the final library is marked requiring exec-stack.

Python import fails with:

ImportError: libopenblas.so.0: cannot enable executable stack as shared object requires: Invalid argument

Is the problem on my end, or is there really a problem?

Answered by loss-and-quick

Jun 18, 2025

@martin-frbg
As was said this helps:

diff --git a/common_arm.h b/common_arm.h
index d6291018b..6efb20c58 100644
--- a/common_arm.h
+++ b/common_arm.h
@@ -114,7 +114,15 @@ static inline int blas_quickdivide(blasint x, blasint y){
	OPENBLAS_ARM_TYPE_FUNCTION \
REALNAME:

-#define EPILOGUE
+#if defined(__ELF__) && defined(__linux__)
+# define GNUSTACK .section        .note.GNU-stack,"",%progbits
+#else
+# define GNUSTACK
+#endif
+
+#define EPILOGUE \
+        .size    REALNAME, .-REALNAME;	\
+        GNUSTACK

#define PROFCODE

diff --git a/common_arm64.h b/common_arm64.h
index 5856898a2..7fd81acc4 100644
--- a/common_arm64.h
+++ b/common_arm64.h
@@ -159,8 +159,15 @@ static inline int blas_q…

View full answer

loss-and-quick · 2025-06-18T00:12:07Z

loss-and-quick
Jun 18, 2025
Author

Build Configuration (ARMv7, 32-bit)

Compiler flags for C/C++
• CPPFLAGS: -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
• CFLAGS/CXXFLAGS: -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -O3 -g0 -D_FORTIFY_SOURCE=1
Compiler flags for Fortran
• FCFLAGS/FFLAGS: -O3 -g0
Build options
• CROSS=1
• TARGET=ARMV7
• USE_THREAD=1
• USE_OPENMP=0
• BINARY=32

0 replies

martin-frbg · 2025-06-18T04:50:58Z

martin-frbg
Jun 18, 2025
Maintainer

This came up recently for IBM Z, but I could not reproduce it on Arm at the time, probably depends on having a very new version of the binutils.
Could you check if adding an EPILOGUE entry in common_arm.h exactly like it was added to common_zarch.h in PR #5197 fixes your problem ?

1 reply

loss-and-quick Jun 18, 2025
Author

This came up recently for IBM Z, but I could not reproduce it on Arm at the time, probably depends on having a very new version of the binutils. Could you check if adding an EPILOGUE entry in common_arm.h exactly like it was added to common_zarch.h in PR #5197 fixes your problem ?

I'm trying to paste EPILOGUE, but getting this errors:

../kernel/arm/iamax_vfp.S: Assembler messages:
../kernel/arm/iamax_vfp.S:478: Error: junk at end of line, first unrecognized character is `,'
../kernel/arm/amax_vfp.S: Assembler messages:
../kernel/arm/amax_vfp.S:444: Error: junk at end of line, first unrecognized character is `,'
../kernel/arm/amax_vfp.S: Assembler messages:
../kernel/arm/amax_vfp.S:444: Error: junk at end of line, first unrecognized character is `,'
make[3]: *** [Makefile.L1:659: ismax_k.o] Error 1
make[3]: *** Waiting for unfinished jobs....
../kernel/arm/iamax_vfp.S: Assembler messages:
../kernel/arm/iamax_vfp.S:478: Error: junk at end of line, first unrecognized character is `,'
make[3]: *** [Makefile.L1:556: samax_k.o] Error 1
make[3]: *** [Makefile.L1:607: smin_k.o] Error 1
make[3]: *** [Makefile.L1:619: isamax_k.o] Error 1
../kernel/arm/iamax_vfp.S: Assembler messages:
../kernel/arm/iamax_vfp.S:478: Error: junk at end of line, first unrecognized character is `,'
make[3]: *** [Makefile.L1:639: isamin_k.o] Error 1
../kernel/arm/amax_vfp.S: Assembler messages:
../kernel/arm/amax_vfp.S:444: Error: junk at end of line, first unrecognized character is `,'
../kernel/arm/amax_vfp.S: Assembler messages:
../kernel/arm/amax_vfp.S:444: Error: junk at end of line, first unrecognized character is `,'
../kernel/arm/axpy_vfp.S: Assembler messages:
../kernel/arm/axpy_vfp.S:565: Error: junk at end of line, first unrecognized character is `,'
make[3]: *** [Makefile.L1:596: smax_k.o] Error 1
make[3]: *** [Makefile.L1:576: samin_k.o] Error 1
../kernel/arm/sdot_vfp.S: Assembler messages:
../kernel/arm/sdot_vfp.S:349: Error: junk at end of line, first unrecognized character is `,'
make[3]: *** [Makefile.L1:718: saxpy_k.o] Error 1
make[3]: *** [Makefile.L1:782: sdot_k.o] Error 1
../kernel/arm/nrm2_vfpv3.S: Assembler messages:
../kernel/arm/nrm2_vfpv3.S:518: Error: junk at end of line, first unrecognized character is `,'
make[3]: *** [Makefile.L1:821: snrm2_k.o] Error 1
../kernel/arm/sum_vfp.S: Assembler messages:
../kernel/arm/sum_vfp.S:424: Error: junk at end of line, first unrecognized character is `,'
make[3]: *** [Makefile.L1:699: ssum_k.o] Error 1
../kernel/arm/asum_vfp.S: Assembler messages:
../kernel/arm/asum_vfp.S:488: Error: junk at end of line, first unrecognized character is `,'
../kernel/arm/iamax_vfp.S: Assembler messages:
../kernel/arm/iamax_vfp.S:478: Error: junk at end of line, first unrecognized character is `,'
make[3]: *** [Makefile.L1:670: ismin_k.o] Error 1
make[3]: *** [Makefile.L1:680: sasum_k.o] Error 1
make[2]: *** [Makefile:199: libs] Error

There is my patch:

diff --git a/common_arm.h b/common_arm.h
index d6291018b..5aa0a100d 100644
--- a/common_arm.h
+++ b/common_arm.h
@@ -114,7 +114,15 @@ static inline int blas_quickdivide(blasint x, blasint y){
 	OPENBLAS_ARM_TYPE_FUNCTION \
 REALNAME:
 
-#define EPILOGUE
+#if defined(__ELF__) && defined(__linux__)
+# define GNUSTACK .section        .note.GNU-stack,"",@progbits
+#else
+# define GNUSTACK
+#endif
+
+#define EPILOGUE \
+        .size    REALNAME, .-REALNAME;	\
+        GNUSTACK
 
 #define PROFCODE
 
diff --git a/common_arm64.h b/common_arm64.h
index 5856898a2..3959b9956 100644
--- a/common_arm64.h
+++ b/common_arm64.h
@@ -159,8 +159,15 @@ static inline int blas_quickdivide(blasint x, blasint y){
 REALNAME:
 .endm
 
+#if defined(__ELF__) && defined(__linux__)
+# define GNUSTACK .section        .note.GNU-stack,"",@progbits
+#else
+# define GNUSTACK
+#endif
 
-#define EPILOGUE
+#define EPILOGUE \
+        .size    REALNAME, .-REALNAME;	\
+        GNUSTACK
 
 #define PROFCODE

loss-and-quick · 2025-06-18T11:19:02Z

loss-and-quick
Jun 18, 2025
Author

@martin-frbg
As was said this helps:

diff --git a/common_arm.h b/common_arm.h
index d6291018b..6efb20c58 100644
--- a/common_arm.h
+++ b/common_arm.h
@@ -114,7 +114,15 @@ static inline int blas_quickdivide(blasint x, blasint y){
	OPENBLAS_ARM_TYPE_FUNCTION \
REALNAME:

-#define EPILOGUE
+#if defined(__ELF__) && defined(__linux__)
+# define GNUSTACK .section        .note.GNU-stack,"",%progbits
+#else
+# define GNUSTACK
+#endif
+
+#define EPILOGUE \
+        .size    REALNAME, .-REALNAME;	\
+        GNUSTACK

#define PROFCODE

diff --git a/common_arm64.h b/common_arm64.h
index 5856898a2..7fd81acc4 100644
--- a/common_arm64.h
+++ b/common_arm64.h
@@ -159,8 +159,15 @@ static inline int blas_quickdivide(blasint x, blasint y){
REALNAME:
.endm

+#if defined(__ELF__) && defined(__linux__)
+# define GNUSTACK .section        .note.GNU-stack,"",%progbits
+#else
+# define GNUSTACK
+#endif

-#define EPILOGUE
+#define EPILOGUE \
+        .size    REALNAME, .-REALNAME;	\
+        GNUSTACK

#define PROFCODE

Can I create PR?

0 replies

martin-frbg · 2025-06-18T11:27:13Z

martin-frbg
Jun 18, 2025
Maintainer

That's unfortunate - I thought it might work. Perhaps it is only the .size line that is not supported on ARM ? It is not directly related to the stack problem so you could try leaving that out

9 replies

loss-and-quick Jun 18, 2025
Author

Seems to build (on a NeoverseN1 in the GCC Compile Farm) but I need to fix the files that do not have any EPILOGUE line at all before I can check if it really removes the executable stack.

Check by execstack

martin-frbg Jun 18, 2025
Maintainer

Doesn't have execstack installed unfortunately, and readelf confusingly shows "RW" rather than "RWE" on the GNU_STACK entry already before the patch. Maybe the older version of binutils did not default to creating an executable stack ??

loss-and-quick Jun 18, 2025
Author

Doesn't have execstack installed unfortunately, and readelf confusingly shows "RW" rather than "RWE" on the GNU_STACK entry already before the patch. Maybe the older version of binutils did not default to creating an executable stack ??

As far as I know in the past, older versions of binutils (GNU linker and assembler) created an executable stack by default if any object file lacked a .note.GNU-stack section

My compiled lib with #5315 (GNU Binutils 2.44):

Elf file type is DYN (Shared object file)
Entry point 0x0
There are 6 program headers, starting at offset 52

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000000 0x00000000 0x00000000 0xa9fa8c 0xa9fa8c R E 0x1000
  LOAD           0xaa0248 0x00aa0248 0x00aa0248 0x08214 0x0ad78 RW  0x1000
  DYNAMIC        0xaa2bb8 0x00aa2bb8 0x00aa2bb8 0x00118 0x00118 RW  0x4
  TLS            0xaa0248 0x00aa0248 0x00aa0248 0x00000 0x0f000 R   0x8
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0x10
  GNU_RELRO      0xaa0248 0x00aa0248 0x00aa0248 0x06db8 0x06db8 R   0x1

 Section to Segment mapping:
  Segment Sections...
   00     .hash .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rel.dyn .rel.plt .init .plt .text .fini .rodata .eh_frame 
   01     .init_array .fini_array .data.rel.ro .dynamic .got .data .bss 
   02     .dynamic 
   03     .tbss 
   04     
   05     .init_array .fini_array .data.rel.ro .dynamic .got

martin-frbg Jun 18, 2025
Maintainer

same as I am seeing, and that machine appears to have binutils 2.44 as well. can't get prelink to build there due to some problem with the installed libelf (or maybe the prelink sources I found are too ancient). guess we can go ahead with your patch for arm in any case, and I can look into what if anything is needed on arm64 later ?

loss-and-quick Jun 18, 2025
Author

same as I am seeing, and that machine appears to have binutils 2.44 as well. can't get prelink to build there due to some problem with the installed libelf (or maybe the prelink sources I found are too ancient). guess we can go ahead with your patch for arm in any case, and I can look into what if anything is needed on arm64 later ?

It will be nice!

“missing .note.GNU-stack section implies executable stack” when building OpenBLAS #5313

Uh oh!

loss-and-quick Jun 18, 2025

Replies: 4 comments · 10 replies

Uh oh!

loss-and-quick Jun 18, 2025 Author

Uh oh!

martin-frbg Jun 18, 2025 Maintainer

Uh oh!

Uh oh!

loss-and-quick Jun 18, 2025 Author

Uh oh!

Uh oh!

loss-and-quick Jun 18, 2025 Author

Uh oh!

martin-frbg Jun 18, 2025 Maintainer

Uh oh!

loss-and-quick Jun 18, 2025 Author

Uh oh!

martin-frbg Jun 18, 2025 Maintainer

Uh oh!

Uh oh!

loss-and-quick Jun 18, 2025 Author

Uh oh!

martin-frbg Jun 18, 2025 Maintainer

Uh oh!

loss-and-quick Jun 18, 2025 Author

loss-and-quick
Jun 18, 2025

Replies: 4 comments 10 replies

loss-and-quick
Jun 18, 2025
Author

martin-frbg
Jun 18, 2025
Maintainer

loss-and-quick Jun 18, 2025
Author

loss-and-quick
Jun 18, 2025
Author

martin-frbg
Jun 18, 2025
Maintainer

loss-and-quick Jun 18, 2025
Author

martin-frbg Jun 18, 2025
Maintainer

loss-and-quick Jun 18, 2025
Author

martin-frbg Jun 18, 2025
Maintainer

loss-and-quick Jun 18, 2025
Author