[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
lib/56395: random profiled binary crash on strictly-aligned CPU
>Synopsis: random profiled binary crash on strictly-aligned CPU
>Arrival-Date: Fri Sep 10 01:30:00 +0000 2021
>Originator: Rin Okuyama
Department of Physics, Meiji University
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
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).
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.
Allocate objects in struct gmonparam with proper alignments:
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
(*) 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?
Main Index |
Thread Index |