On Wed, Aug 3, 2022 at 9:26 AM Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > On Wed, Aug 3, 2022 at 8:16 AM Jens Axboe <axboe@xxxxxxxxx> wrote: > > > > On the topic of warnings, on my new build box I get a lot of these: > > > > ld: warning: arch/x86/lib/putuser.o: missing .note.GNU-stack section implies executable stack > > ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker > > > > which ends up polluting the output quite a bit. > > > > axboe@r7525 ~> ld --version > > GNU ld (GNU Binutils for Debian) 2.38.90.20220713 > > Ok, I have binutils 2.37, so it may be new to 2.38. > > Some googling around seems to imply that we'd need to so something like this > > .section .note.GNU-stack,"",%progbits > > in all our *.S files. > > We do have some signs of that in our tooling, because apparently it > has hit user-space, but I wonder what has triggered the need on the > kernel side for you. > > I'd hate to add that pointless line to every asm file, but maybe we > could so something like this > > #ifdef __ASSEMBLY_ > #ifdef OUTPUT_PROGBITS > .section .note.GNU-stack,"",%progbits > #undef OUTPUT_PROGBITS > #endif > #endif > > and then change our 'AS' command line to do '-DOUTPUT_PROGBITS' in our > makefiles. > > *Most* asm files should include <linux/linkage.h> just for all the > macros that declare variables externally, so that might catch the bulk > of it. > > Somebody who knows the rules better than I would be a good idea. $ as --help | grep exec --execstack require executable stack for this object --noexecstack don't require executable stack for this object --statistics print various measured statistics from execution Does adding `--noexecstack` to KBUILD_ASFLAGS for these architectures help, rather than modifying every assembler source? > > I've added random people who have touched those linkage things in the > past to the participants, in the hope that somebody goes, "No, Linus, > just add flag XYZ to the linker script" or other and there's a clear > and obvious solution. > > Linus -- Thanks, ~Nick Desaulniers
