Currently, checkstack.pl only looks for fixed subtractions from the stack
pointer.  However, things like this:

void function(int size)
{
        char stackbuster[size << 2];
...

are certainly worth pointing out, I think.

This could perhaps be done more cleanly, and the following patch only
adds "dynamic" REs for x86 and x86_64, but it works:

0x00b0 crypto_cbc_decrypt_inplace [cbc]:                Dynamic (%rax)
0x00ad crypto_pcbc_decrypt_inplace [pcbc]:              Dynamic (%rax)
0x02f6 crypto_pcbc_encrypt_inplace [pcbc]:              Dynamic (%rax)
0x036c _crypto_xcbc_digest_setkey [xcbc]:               Dynamic (%rax)
...

(Inspired by Keith Owens' old stack-check script)

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
---

Index: linux-2.6.25/scripts/checkstack.pl
===================================================================
--- linux-2.6.25.orig/scripts/checkstack.pl	2008-05-02 12:18:15.426407528 -0500
+++ linux-2.6.25/scripts/checkstack.pl	2008-05-02 12:18:25.989469552 -0500
@@ -26,8 +26,12 @@
 # $& (whole re) matches the complete objdump line with the stack growth
 # $1 (first bracket) matches the size of the stack growth
 #
+# $dre is similar, but for dynamic stack redutions:
+# $& (whole re) matches the complete objdump line with the stack growth
+# $1 (first bracket) matches the dynamic amount of the stack growth
+#
 # use anything else and feel the pain  ;) 
-my (@stack, $re, $x, $xs);
+my (@stack, $re, $dre, $x, $xs);
 {
 	my $arch = shift;
 	if ($arch eq "") {
@@ -47,9 +51,11 @@ my (@stack, $re, $x, $xs);
 	} elsif ($arch =~ /^i[3456]86$/) {
 		#c0105234:       81 ec ac 05 00 00       sub    $0x5ac,%esp
 		$re = qr/^.*[as][du][db]    \$(0x$x{1,8}),\%esp$/o;
+		$dre = qr/^.*[as][du][db]    (%.*),\%esp$/o;
 	} elsif ($arch eq 'x86_64') {
 		#    2f60:	48 81 ec e8 05 00 00 	sub    $0x5e8,%rsp
 		$re = qr/^.*[as][du][db]    \$(0x$x{1,8}),\%rsp$/o;
+		$dre = qr/^.*[as][du][db]    (\%.*),\%rsp$/o;
 	} elsif ($arch eq 'ia64') {
 ...
[ message continues ]

These two could join a line.  Otherwise an excellent addition.

Reviewed-By: Joern Engel <joern@logfs.org>

Jörn

-- 
"Translations are and will always be problematic. They inflict violence
upon two languages." (translation from German)
--

[ message continues ]

Thanks... was just following the existing style (in this part of the
file, anyway...)


--

[ message continues ]