Tests using num2name on aarch64 and powerpc making stack frames too large

[William Cohen <wcohen at redhat dot com>]

I noticed that several using the mapping syscall number to number
(eventcount.stp, stopwatches.stp, syscallbypid-nd.stp,
syscalls_by_pid.stp, etc.) are failing to build on powerpc and aarch64
because the stack frame gets too large. Below is an example error
message from aarch64:

# uname -a
Linux apm-mustang-b0-03.khw3.lab.eng.bos.redhat.com 4.20.8-200.fc29.aarch64 #1 SMP Wed Feb 13 12:48:07 UTC 2019 aarch64 aarch64 aarch64 GNU/Linux
[root@apm-mustang-b0-03 general]# stap -kp4 stopwatches.stp
/tmp/stapCwv6n4/stap_17506_src.c: In function ‘probe_6233’:
/tmp/stapCwv6n4/stap_17506_src.c:19796:1: error: the frame size of 2480 bytes is larger than 512 bytes [-Werror=frame-larger-than=]
 }
 ^
cc1: all warnings being treated as errors
make[1]: *** [scripts/Makefile.build:291: /tmp/stapCwv6n4/stap_17506_src.o] Error 1
make: *** [Makefile:1566: _module_/tmp/stapCwv6n4] Error 2
WARNING: kbuild exited with status: 2

Similar one from the systemtap.log of powerpc running fedora28:

meta taglines 'test_check: stap -p4 stopwatches.stp' tag 'test_check' value 'st\
ap -p4 stopwatches.stp'
attempting command stap -p4 stopwatches.stp
OUT /tmp/stap9RmrVQ/stap_f1ded880c455ea3e6f3cfee5825a4681_144076_src.c: In func\
tion 'probe_6410':
/tmp/stap9RmrVQ/stap_f1ded880c455ea3e6f3cfee5825a4681_144076_src.c:20714:1: err\
or: the frame size of 2912 bytes is larger than 512 bytes [-Werror=frame-larger\
-than=]
 }
 ^
cc1: all warnings being treated as errors


This error is from begin probe that initialize the associative arrays
between syscall number and names.  It looks like the code is
allocating a lot of space for temporaries.  Maybe as a result of how
these processors are reuse argument values between the _stp_map_set_is
and _stp_mapset_si calls. For example see the following in the
disassembled code where x3 is value is being save before the call to
_stp_map_set_is then be loaded int x1 before the call to
_stp_map_set_si:


    5f14:       90000000        adrp    x0, 0 <enter_tracepoint_probe_0>
    5f18:       91000003        add     x3, x0, #0x0
    5f1c:       90000000        adrp    x0, 0 <enter_tracepoint_probe_0>
    5f20:       91000000        add     x0, x0, #0x0
    ..
    5f48:       f9003fe3        str     x3, [sp, #120]
    5f4c:       97fff75f        bl      3cc8 <_stp_map_set_is>
    5f50:       35090140        cbnz    w0, 17f78 <probe_6233+0x12468>
    5f54:       90000001        adrp    x1, 0 <enter_tracepoint_probe_0>
    5f58:       91000021        add     x1, x1, #0x0
    5f5c:       f9025b21        str     x1, [x25, #1200]
    5f60:       d2800144        mov     x4, #0xa                        // #10
    5f64:       f9401b80        ldr     x0, [x28, #48]
    5f68:       f9027f24        str     x4, [x25, #1272]
    5f6c:       f9403fe1        ldr     x1, [sp, #120]
    5f70:       aa0403e2        mov     x2, x4
    5f74:       97fff50b        bl      33a0 <_stp_map_set_si>

This str/ldr pattern repeats through the code through the function
with larger and larger constant.  This is probably a result of the
compiler attempting to avoid regenerate a pointer with multiple
adrp/add sequence.

Any thoughts on how the compiler might be convinced to trade time for
space so code doesn't exceed the allowed stack size?

-Will