Re: kernel stack usage

[Jaromír Doleček <jaromir.dolecek%gmail.com@localhost>]

Can anybody using clang please confirm kernel build with
-Wframe-larger-than=3584?

Kamil - what's the difference in gcc between -Wframe-larger-than= and
-Wstack-size= ?

I see according to gcc documentation -Wframe-larger-than doesn't count
size for alloca() and variable-length arrays, which makes it much less
useful than -Wstack-usage.

Jaromir

Le dim. 31 mai 2020 à 16:39, Kamil Rytarowski <kamil%netbsd.org@localhost> a écrit :
>
> Can we adopt -Wframe-larger-than=1024 and mark it fatal?
>
> This option is supported by GCC and Clang.
>
> On 31.05.2020 15:55, Jaromír Doleček wrote:
> > I think it would make sense to add -Wstack-usage=X to kernel builds.
> >
> > Either 2KB or 1KB seems to be good limit, not too many offenders
> > between 1KB and 2KB so maybe worth it to use 1KB and change them.
> >
> > I'm sure there would be something similar for LLVM too.
> >
> > Jaromir
> >
> > Le dim. 31 mai 2020 à 15:39, Simon Burge <simonb%netbsd.org@localhost> a écrit :
> >>
> >> matthew green wrote:
> >>
> >>> glad to see this effort and the clean up already!
> >>>
> >>> ideally, we can break the kernel build if large stack consumers
> >>> are added to the kernel.  i'd be OK with it being default on,
> >>> with of course a way to skip it, and if necessary it can have
> >>> a whitelist of "OK large users."
> >>
> >> I started to look at -fstack-usage which gives a nice MI way of getting
> >> the data instead of parsing MD objdump output, but didn't get any
> >> further than the below patch.  The find(1) command referenced in the
> >> patch gives the following
> >>
> >>   1008 nfs_serv.c:2181:1:nfsrv_link
> >>   1056 procfs_linux.c:422:1:procfs_do_pid_stat
> >>   1056 vfs_subr.c:1521:1:vfs_buf_print
> >>   1072 dl_print.c:80:1:sdl_print
> >>   1104 core_elf32.c:300:1:coredump_getseghdrs_elf32
> >>   1104 core_elf32.c:300:1:coredump_getseghdrs_elf64
> >>   1104 sys_ptrace_common.c:1595:1:proc_regio
> >>   1120 subr_bufq.c:131:1:bufq_alloc
> >>   1136 db_lwp.c:64:1:db_lwp_whatis
> >>   1152 kern_ktrace.c:1269:1:ktrwrite
> >>   1168 uvm_swap.c:768:1:uvm_swap_stats.part.1
> >>   1312 nfs_serv.c:1905:1:nfsrv_rename
> >>   2112 tty_60.c:68:1:compat_60_ptmget_ioctl
> >>   2144 memmem.c:83:14:twoway_memmem
> >>
> >> Anyone else want to run with adding a bit more to this to do some build
> >> failure as mrg@ suggests and documenting for options(4)?
> >>
> >> Cheers,
> >> Simon.
> >> --
> >> Index: Makefile.kern.inc
> >> ===================================================================
> >> RCS file: /cvsroot/src/sys/conf/Makefile.kern.inc,v
> >> retrieving revision 1.270
> >> diff -d -p -u -r1.270 Makefile.kern.inc
> >> --- Makefile.kern.inc   21 May 2020 18:44:19 -0000      1.270
> >> +++ Makefile.kern.inc   31 May 2020 13:34:13 -0000
> >> @@ -104,6 +104,11 @@ CFLAGS+=   -ffreestanding -fno-zero-initia
> >>  CFLAGS+=       ${${ACTIVE_CC} == "gcc":? -fno-delete-null-pointer-checks :}
> >>  CFLAGS+=       ${DEBUG} ${COPTS}
> >>  AFLAGS+=       -D_LOCORE -Wa,--fatal-warnings
> >> +.if defined(KERN_STACK_USAGE)
> >> +# example usage to find largest stack users in kernel compile directory:
> >> +#    find . -name \*.su | xargs awk '{ printf "%6d %s\n", $2, $1 }' | sort +1n
> >> +CFLAGS+=       -fstack-usage
> >> +.endif
> >>
> >>  # XXX
> >>  .if defined(HAVE_GCC) || defined(HAVE_LLVM)
> >> @@ -338,8 +343,8 @@ ${_s:T:R}.o: ${_s}
> >>  .if !target(__CLEANKERNEL)
> >>  __CLEANKERNEL: .USE
> >>         ${_MKMSG} "${.TARGET}ing the kernel objects"
> >> -       rm -f ${KERNELS} *.map eddep tags *.[io] *.ko *.ln [a-z]*.s vers.c \
> >> -           [Ee]rrs linterrs makelinks assym.h.tmp assym.h \
> >> +       rm -f ${KERNELS} *.map *.[io] *.ko *.ln [a-z]*.s *.su vers.c \
> >> +           eddep tags [Ee]rrs linterrs makelinks assym.h.tmp assym.h \
> >>             ${EXTRA_KERNELS} ${EXTRA_CLEAN}
> >>  .endif
> >>
>
>