Re: Kernel stack hogs list available
Julian Elischer wrote: I ported the code to allow gcc to report functions that use too much of our 3.4KB kernel stacks. Very cool! None of these are dangerous for the stuff I've done so far. Someone else anticipated the question I was going to ask: thanks for the patch, too! -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Kernel stack hogs list available
On Wed, 15 Aug 2001, Julian Elischer wrote: I ported the code to allow gcc to report functions that use too much of our 3.4KB kernel stacks. Julian, This is way cool stuff. I assume these are done based on i386 stack frame layouts? Running on other platforms will result in different alignment (minor issue, as most of the time it will just be a few bytes here or there), and some different code (specifically, alpha/, ia64/, etc). Together with functional cross-compiling, this could be a very useful tool indeed. Perhaps someone on the alpha side could do the same test run on that platform? Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Kernel stack hogs list available
At 11:29 AM -0400 8/16/01, Robert Watson wrote: This is way cool stuff. I assume these are done based on i386 stack frame layouts? Running on other platforms will result in different alignment (minor issue, as most of the time it will just be a few bytes here or there), and some different code (specifically, alpha/, ia64/, etc). Together with functional cross-compiling, this could be a very useful tool indeed. Perhaps someone on the alpha side could do the same test run on that platform? Also, the number of registers and compiler flags such as optimization will cause different register spills to occur. You can't just count up the bytes by looking at the code, it needs to be done in the compiler alongside register allocation. I know we only recommend -O compilations but other flags could affect the count. Mark To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Kernel stack hogs list available
May I ask where to get this utility? Thanks! Julian Elischer [EMAIL PROTECTED] said: I ported the code to allow gcc to report functions that use too much of our 3.4KB kernel stacks. I tried it ou ton a compile of GENERIC. it produced some 360 functions that allocate over 100 bytes on the stack. The list is available at: http://people.freebsd.org/~julian/stack-hogs It's quite interesting reading. I set the limit size to 100 bytes per frame as that seems a reasonable size to do must things. (remember the catch-phrase in teh kernel is no big structures on the stack) Consider that many functions call each other, and some can even be recursive, I find it easy to believe that some of teh off crashes I've seen over the years may have come from teh 3.5KB being exhusted and the stack wandering into the u-area where results would be 'dodgy' at best. Please take a look and see if any of your pet projects is listed here.. for a quick example here are teh files where over 1K is being allocated on the stack! dev/ata/atapi-cd.c:1804: 2068 byte frame dev/ata/ata-raid.c:524: 2056 byte frame dev/ata/atapi-cd.c:1055: 1756 byte frame net/if_sl.c:778: 1540 byte frame dev/usb/ugen.c:694: 1168 byte frame dev/an/if_an.c:1572: 1112 byte frame dev/wi/if_wi.c:1647: 1096 byte frame dev/usb/usb_subr.c:897: 1088 byte frame kern/imgact_elf.c:668: 1072 byte frame dev/usb/ums.c:358: 1056 byte frame dev/usb/ukbd.c:182: 1048 byte frame dev/awi/awi_wicfg.c:328: 1044 byte frame netinet6/nd6.c:2225: 1040 byte frame dev/usb/uhid.c:252: 1040 byte frame dev/awi/awi_wicfg.c:626: 1040 byte frame dev/usb/uscanner.c:322: 1036 byte frame dev/usb/urio.c:439: 1036 byte frame dev/usb/ulpt.c:333: 1036 byte frame dev/usb/if_cue.c:554:1036 byte frame dev/usb/if_aue.c:752:1036 byte frame dev/usb/urio.c:508: 1032 byte frame dev/usb/urio.c:290: 1032 byte frame dev/usb/ugen.c:767: 1032 byte frame dev/wi/if_wi.c:2345: 1028 byte frame dev/wi/if_wi.c:2258: 1028 byte frame dev/usb/umass.c:968: 1028 byte frame dev/usb/ugen.c:228: 1028 byte frame dev/usb/if_kue.c:511:1028 byte frame netinet6/nd6.c:2151: 1024 byte frame Remember these are only in GENERIC. Julian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- Rex Luo Tel : 886-2-25521814 Ext. 824 Fax : 886-2-25521824 e-mail : [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Kernel stack hogs list available
On Thu, 16 Aug 2001, Rex Luo wrote:
May I ask where to get this utility?
Thanks!
It's beeing added to gcc in -current..
here are my patches: WARNING..CUT_N_PASTE.. will not patch cleanly.
Index: calls.c
===
RCS file: /usr/home/cvs/src/contrib/gcc.295/calls.c,v
retrieving revision 1.1.1.5
diff -u -r1.1.1.5 calls.c
--- calls.c 2001/02/17 08:35:01 1.1.1.5
+++ calls.c 2001/08/15 22:07:43
@@ -2293,6 +2293,16 @@
/* All arguments and registers used for the call must be set up by
now! */
+ if (warn_arglist_size_flag)
+{
+ if (unadjusted_args_size warn_arglist_size)
+{
+ warning (%d byte arglist in function call,
unadjusted_args_size);
+ warning (exceeds user specified limit (%d bytes),
+ warn_arglist_size);
+}
+}
+
/* Generate the actual call instruction. */
emit_call_1 (funexp, fndecl, funtype, unadjusted_args_size,
args_size.constant, struct_value_size,
Index: flags.h
===
RCS file: /usr/home/cvs/src/contrib/gcc.295/flags.h,v
retrieving revision 1.4
diff -u -r1.4 flags.h
--- flags.h 1999/10/26 08:45:23 1.4
+++ flags.h 2001/08/15 22:07:43
@@ -121,6 +121,18 @@
extern int warn_template_debugging;
+/* Nonzero means warn if a frame is larger that N bytes. The value
+ of N is warn_frame_size. */
+
+extern int warn_frame_size_flag;
+extern int warn_frame_size;
+
+/* Nonzero means warn if a function call pushes more than N bytes
+ onto the stack. The value of N is warn_arglist_size. */
+
+extern int warn_arglist_size_flag;
+extern int warn_arglist_size;
+
/* Nonzero means warn about any identifiers that match in the first N
characters. The value N is in `id_clash_len'. */
Index: invoke.texi
===
RCS file: /usr/home/cvs/src/contrib/gcc.295/invoke.texi,v
retrieving revision 1.8
diff -u -r1.8 invoke.texi
--- invoke.texi 2001/02/17 09:04:50 1.8
+++ invoke.texi 2001/08/15 22:07:43
@@ -122,13 +122,13 @@
@xref{Warning Options,,Options to Request or Suppress Warnings}.
@smallexample
-fsyntax-only -pedantic -pedantic-errors
--w -W -Wall -Waggregate-return -Wbad-function-cast
--Wcast-align -Wcast-qual -Wchar-subscripts -Wcomment
--Wconversion -Werror -Wformat
+-w -W -Wall -Waggregate-return -Warglist-size-@var{n}
+-Wbad-function-cast -Wcast-align -Wcast-qual -Wchar-subscripts
+-Wcomment -Wconversion -Werror -Wformat
-Wid-clash-@var{len} -Wimplicit -Wimplicit-int
-Wimplicit-function-declaration -Wimport
--Werror-implicit-function-declaration -Winline
--Wlarger-than-@var{len} -Wlong-long
+-Werror-implicit-function-declaration -Wframe-size-@var{n}
+-Winline -Wlarger-than-@var{len} -Wlong-long
-Wmain -Wmissing-declarations -Wmissing-noreturn
-Wmissing-prototypes -Wmultichar -Wnested-externs -Wno-import
-Wparentheses -Wpointer-arith -Wredundant-decls
@@ -1811,6 +1811,17 @@
the warning messages, use @samp{-Wno-long-long}. Flags
@samp{-Wlong-long} and @samp{-Wno-long-long} are taken into account
only when @samp{-pedantic} flag is used.
+
+@item -Wframe-size-@var{n}
+Warn if a frame uses greater than @var{n} bytes. This warning can be
useful
+when stack space is limited, as is typical in embedded
environments. This
+warning, and also @samp{-Warglist-size-@var{n}}, can help locate
functions
+who may contribute to a stack overrun.
+
+@item -Warglist-size-@var{n}
+Warn if function argument list uses greater than @var{n} bytes. As with
+@samp{-Wframe-size-@var{n}}, this warning can help locate functions who
+may contribute to a stack overrun.
@item -Werror
Make all warnings into errors.
Index: toplev.c
===
RCS file: /usr/home/cvs/src/contrib/gcc.295/toplev.c,v
retrieving revision 1.11
diff -u -r1.11 toplev.c
--- toplev.c2001/02/17 09:06:31 1.11
+++ toplev.c2001/08/15 22:07:44
@@ -1075,6 +1075,10 @@
{ -Wlong-long, },
{ -Wno-long-long, Do not warn about using 'long long' when
-pedantic },
{ -Wmain, Warn about suspicious declarations of main },
+ { -Wframe-size-N ,
+ Warn if frame uses greater than N bytes. },
+ { -Warglist-size-N ,
+ Warn if function argument list uses greater than N bytes. },
{ -Wno-main, },
{ -Wmissing-braces,
Warn about possibly missing braces around initialisers },
@@ -1229,6 +1233,18 @@
int warn_cast_align;
+/* Nonzero means warn if a frame is larger that N bytes. The value
+ of N is warn_frame_size. */
+
+int warn_frame_size_flag=0;
+int warn_frame_size;
+
+/* Nonzero means warn if a function call pushes more than N bytes
+ onto the stack. The value of N is warn_arglist_size. */
+
+int warn_arglist_size_flag=0;
+int warn_arglist_size;
+
/* Nonzero means warn about any identifiers that match in the first N
characters.
Re: Kernel stack hogs list available
On Wed, Aug 15, 2001 at 04:00:50PM -0700, Julian Elischer wrote: I ported the code to allow gcc to report functions that use too much of our 3.4KB kernel stacks. Actually I thought I did. :-) Is your final patch different from the one I did and sent you? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Kernel stack hogs list available
I guess so, I started from the code that was on the gcc web page.. did you send me something new? (I sent you a copy of the final version.. di you miss it? I missed yours :-) On Wed, 15 Aug 2001, David O'Brien wrote: On Wed, Aug 15, 2001 at 04:00:50PM -0700, Julian Elischer wrote: I ported the code to allow gcc to report functions that use too much of our 3.4KB kernel stacks. Actually I thought I did. :-) Is your final patch different from the one I did and sent you? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
