lib/56395: random profiled binary crash on strictly-aligned CPU

[rokuyama%meiji.ac.jp@localhost]

>Number:         56395
>Category:       lib
>Synopsis:       random profiled binary crash on strictly-aligned CPU
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    lib-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Sep 10 01:30:00 +0000 2021
>Originator:     Rin Okuyama
>Release:        9.99.88
>Organization:
Department of Physics, Meiji University
>Environment:
NetBSD hdlu 9.99.88 NetBSD 9.99.88 (GENERIC) #18: Wed Sep  8 16:29:48 JST 2021  rin@latipes:/sys/arch/landisk/compile/GENERIC landisk
>Description:
Profiled binaries, e.g., *_profile tests in ATF, ``randomly'' crash in
_mcount() due to alignment faults on strictly-aligned CPUs, namely,
SH-4 (sh3) and IBM403 (powerpc/ibm4xx).
>How-To-Repeat:
Run *_profile tests in ATF. Some work and others does not. Seems almost
randomly depending on which versions of source codes they are built from.
>Fix:
Allocate objects in struct gmonparam with proper alignments:

https://gist.github.com/rokuyama/98b3d33222781337dc80e4e9a75da121

This is especially important for monstartup(), where objects are
allocated on heap; break is not guaranteed to be aligned at all,
unlike stack pointer.

Even for _m_gmon_alloc(), where objects are allocated on anonymous
memory, p->tos is not aligned properly in general.

This fixes ``random'' crashes for profile tests on SH-4 and IBM403 (*).
Also, no regression is observed for others, e.g., aarch64 and IBM405
(powerpc/ibm4xx).

(*) Timeout should be increased for some tests. ``pic'' variants still
fail as expected. Dynamically-linked binaries also crash in rtld for
SH-4, but this seems different problem...

Note that this should not cause any ABI breakage, as long as
applications use proper pointers; use p->tos instead of evil pointer
arithmetic like (struct tostruct *)((char *)p->froms + p->fromssize).

(This example did not work before, since the order of froms[] and
tos[] in struct gmonparam is reversed depending which of monstartup()
or _m_gmon_alloc() is used to allocate it...)

OK to commit? Or am I missing something?