toolchain/55837: GCC 9.3 g++ generates wrong codes for hard-float arm

[rokuyama.rk%gmail.com@localhost]

>Number:         55837
>Category:       toolchain
>Synopsis:       GCC 9.3 g++ generates wrong codes for hard-float arm
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    toolchain-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Dec 02 09:00:00 +0000 2020
>Originator:     Rin Okuyama
>Release:        7.99.76
>Organization:
Department of Physics, Meiji University
>Environment:
NetBSD rpi0w 9.99.76 NetBSD 9.99.76 (RPI0EB) #12: Tue Dec  1 11:02:35 JST 2020  rin@latipes:/build/work/src/sys/arch/evbarm/compile/RPI0EB evbarm
>Description:
g++ from GCC 9.3 generates wrong codes for hard-float arm variants, i.e.,
earmv[5-7]hf{,eb}. The situation is much more serious on v[5-6]hf{eb},
but v7hf{,eb} is also affected. On the other hand, soft-float variants,
earmv[4-7] seem not affected as far as I can see.

For GDB on v[5-6]hf, trying to place breakpoint on non-existent symbol
causes abort:

on v7hf{,eb}:

|(gdb) b non_existent_symbol
|Function "non_existent_symbol" not defined.
|Make breakpoint pending on future shared library load? (y or [n])

on v[5-6]hf{,eb}:

|(gdb) b non_existent_symbol
|terminate called after throwing an instance of 'gdb_exception_RETURN_MASK_ERROR'
|[1]   Abort trap (core dumped) gdb ./hello

Or backtrace longer than one display screen cannot quit by ``q'':

on v7hf{,eb}:

|(gdb) bt
|...
|--Type <RET> for more, q to quit, c to continue without paging--q
|Quit
|(gdb)

on v[5-6]hf{,eb}:

|(gdb) bt
|...
|--Type <RET> for more, q to quit, c to continue without paging--q
|terminate called after throwing an instance of 'gdb_exception_RETURN_MASK_QUIT'
|[1]   Abort trap (core dumped) gdb atf-run atf-run.core

Note that even v7hf{,eb} is affected; we already works around similar
failure in exception handling on v7hf{,eb}. See doc/HACKS:

	https://nxr.netbsd.org/xref/src/doc/HACKS#978

or toolchain/54820:

	http://gnats.netbsd.org/54820

The failures do not occur on soft-float arm variants as far as I can see.

On hard-float arm variants, if whole GDB is compiled with -O0, they do not
occur. Alternatively, compiling GDB by GCC 8.4 remarkably mitigates the
problems, although GCC8 is not perfect; hack described above was initially
introduced for GCC8.

Even if the other parts of userland, shared-libs, rtld, etc., are compiled
by GCC8, the problems occur when GDB itself is compiled by GCC9.

For ATF on v[5-6]hf{,eb}, atf-run aborts like:

on v[5-6]hf{,eb}

| # atf-run | atf-report
| ...
| atf-c/detail/fs_test (3/68): 24 test cases
|    eaccess: [0.021425s] Passed.
|    exists: terminate called after throwing an instance of 'tools::parser::parse_error'
|  what():  LONELY PARSE ERROR: 237: Unexpected token `<<EOF>>'; expected end of
|test case or test case's stdout/stderr line
|[1]   Segmentation fault (core dumped) atf-run |
|      Abort trap (core dumped) atf-report
| #

Many tests in /usr/tests/atf fail due to ``Failed: Test program received
signal 6 (core dumped)''.

These failures do not occur on soft-float variants. If all source codes of
ATF are compiled with -O0, these do not occur also.
>How-To-Repeat:
On earmv[5-6]hf{,eb} machines,

# gdb hello
...
(gdb) b non-existent-symbol

or

# cd /usr/tests/atf && atf-run | atf-report

The problems also occurs for COMPAT_NETBSD32 on aarch64{,eb}.
>Fix:
Exception handling is suspicious, but I haven't still figured out what
actually happens. Note that while other OS's use arm specific exception
handling, NetBSD uses normal DWARF exception handling based on libunwind.