* Tests using num2name on aarch64 and powerpc making stack frames too large
@ 2019-02-19 4:27 William Cohen
0 siblings, 0 replies; only message in thread
From: William Cohen @ 2019-02-19 4:27 UTC (permalink / raw)
To: systemtap
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
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2019-02-19 4:27 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-02-19 4:27 Tests using num2name on aarch64 and powerpc making stack frames too large William Cohen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).