Bug 89493

Summary: [9/10/11/12 Regression] Stack smashing on armv7hl
Product: gcc Reporter: Pavel Zhukov <pavel>
Component: adaAssignee: Not yet assigned to anyone <unassigned>
Status: WAITING ---    
Severity: normal CC: ebotcazou
Priority: P4    
Version: 9.0   
Target Milestone: 9.5   
Host: Target: armv7hl
Build: Known to work:
Known to fail: Last reconfirmed: 2019-03-08 00:00:00
Attachments: reproducer

Description Pavel Zhukov 2019-02-25 14:00:40 UTC
Created attachment 45816 [details]
reproducer

Reporting this for ada as reproducer is part of gprbuild (gprinstall) code.

In some cases (return from exception handler) stack pointer is set to weird value and either stack smashing protection or storage error occurs.

it's easy and 100% reproducible in Fedora linux distribution 
https://bugzilla.redhat.com/show_bug.cgi?id=1677173

gcc-9.0.1-0.4.fc30.armv7hl
gprbuild-2018-12.fc30.armv7hl

All other architectures (x86, s390x, ppc64le and aarch64 work fine)

We were able to strip reproducer to ~200 LOC (attached) 

# gprbuild -v -cargs:Ada -O2 -g


# valgrind ./exe/process
==29563== Memcheck, a memory error detector
==29563== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==29563== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==29563== Command: ./exe/process
==29563== 
warning: file does not exist '/tmp/a/satrace.log'
==29563== Warning: client switching stacks?  SP change: 0xbdef07c0 --> 0x68818
==29563==          to suppress, use: --max-stackframe=1108836440 or greater
aaa
==29563== Invalid write of size 4
==29563==    at 0x40C04: system__secondary_stack__ss_release (in /tmp/test/exe/process)
==29563==  Address 0x68754 is 12 bytes inside data symbol "ada_main__sec_default_sized_stacks"
==29563== 
==29563== Invalid read of size 4
==29563==    at 0x1A09C: _ada_process (process.adb:119)
==29563==  Address 0x687ec is 164 bytes inside data symbol "ada_main__sec_default_sized_stacks"
==29563== 
==29563== Invalid read of size 4
==29563==    at 0x1A0A4: _ada_process (process.adb:119)
==29563==  Address 0xe1a02026 is not stack'd, malloc'd or (recently) free'd
Comment 1 Matthew Malcomson 2019-03-08 17:35:45 UTC
I've reproduced manually using the reproducer and a bootstrapped gcc at r268766

gcc r265397 does not reproduce the problem.

Hence I'm marking this as a regression.

Between these two versions bootstrap with the configure line below fails.

../gcc-source/configure --enable-bootstrap --enable-languages=c,c++,fortran,objc,obj-c++,ada,lto --prefix=${HOME}/gcc-install --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl --enable-gnu-indirect-function --disable-sjlj-exceptions --with-tune=generic-armv7-a --with-arch=armv7-a --with-float=hard --with-fpu=vfpv3-d16 --with-abi=aapcs-linux --build=armv7hl-redhat-linux-gnueabi

(mostly taken from the configure shown in `gcc -v` from the given package version)
Comment 2 Wilco 2019-03-19 13:56:04 UTC
So is this an Ada unwind bug? What kind of unwinder does Ada use?
Comment 3 Eric Botcazou 2019-03-25 10:44:32 UTC
Does this happen at -O1 too?  If not, can you try and disable strict aliasing or scheduling (or other -O2 optimizations) and see what happens?
Comment 4 Jakub Jelinek 2019-05-03 09:15:12 UTC
GCC 9.1 has been released.
Comment 5 Jakub Jelinek 2019-08-12 08:54:47 UTC
GCC 9.2 has been released.
Comment 6 Jakub Jelinek 2020-03-12 11:58:42 UTC
GCC 9.3.0 has been released, adjusting target milestone.
Comment 7 Richard Biener 2021-06-01 08:13:10 UTC
GCC 9.4 is being released, retargeting bugs to GCC 9.5.