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 <[email protected]> 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 <[email protected]> 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 > >> > >
