bug#49509: libsigsegv fails to build on emulated aarch64 [core-updates]

[Sarah Morgensen <iskarian@mgsn.dev>]

Hi all,

Ludovic Courtès <ludo@gnu.org> writes:

> Hello,
>
> Maxime Devos <maximedevos@telenet.be> skribis:
>
>> Ludovic Courtès schreef op zo 11-07-2021 om 00:19 [+0200]:
>>> Hi,
>>> 
>>> Maxime Devos <maximedevos@telenet.be> skribis:
>>> 
>>> > FAIL: stackoverflow1
>>> > ====================
>>> > 
>>> > qemu: uncaught target signal 11 (Segmentation fault) - core dumped
>>> > FAIL stackoverflow1 (exit status: 139)
>>> > 
>>> > FAIL: stackoverflow2
>>> > ====================
>>> > 
>>> > Starting recursion pass 1.
>>> > Stack overflow 1 missed.
>>> > FAIL stackoverflow2 (exit status: 1)
>>> 
>>> For now I worked around it by offloading this to a “real” machine
>>> (overdrive1), where it builds fine.  I wonder if there’s much we can do
>>> regarding QEMU’s behavior here.
>>
>> Maybe detect if QEMU is used, and if so, don't run the test suite?
>> Not really a ‘clean’ solution though, w.r.t. reproducibility,
>> and I wouldn't know how to detect this.
>
> Yeah, I’d rather avoid that.
>
>> If this is a bug in QEMU, then ideally that would be fixed in QEMU,
>> but I wouldn't know where to look.
>
> It could be that someone else on the intertubes stumbled upon that
> issue, that’d be great.  It could be that libsigsegv plays tricks that
> don’t fare well with QEMU’s expectations, as in
> <https://bugzilla.redhat.com/show_bug.cgi?id=1493304#c5>.  We should ask
> on bug-libsigsegv@gnu.org.
>
> Thanks,
> Ludo’.

(I just realized I never actually replied to this!)

Configuring with "--disable-stackvma" seems to fix this.  Doing this
makes libsigsegv use a different heuristic for determining if a SIGSEGV
was a stack overflow.  I don't think it should impact functionality.
Perhaps just apply that to aarch64 until there's a proper fix?

This is probably a QEMU bug... I will try to report this to upstream
QEMU when I can, as I can't find my notes on this right now.

--
Sarah