Re: CVS commit: src/sys/lib/libunwind

2021-05-31 Thread Rin Okuyama

Correction:

On 2021/06/01 7:10, Rin Okuyama wrote:

On 2021/05/31 23:35, Joerg Sonnenberger wrote:

On Mon, May 31, 2021 at 12:12:24PM +, Rin Okuyama wrote:

Bump LAST_REGISTER and LAST_RESTORE_REG to REGNO_ARM32_S31 for arm.


This is not desirable as it significantly increases the memory use.
The goal here is to actually alias the single and double register in the
space. That's what the existing was doing.


Existing code did not.

With LAST_REGISTER = REGNO_ARM32_D31, libunwind gave up unwinding frames
when it encounters s0-s31; see parseInstructions():

https://nxr.netbsd.org/xref/src/sys/lib/libunwind/DwarfParser.hpp#parseInstructions


This paragraph:


And with LAST_RESTORE_REG = REGNO_ARM32_D31, it did not copy-back contents
of s0-s31 at all; see stepWithDwarf():

https://nxr.netbsd.org/xref/src/sys/lib/libunwind/DwarfInstructions.hpp#136


is only applied to the case of LAST_REGISTER = REGNO_ARM32_S31, and
not to existing code.

However, LAST_RESTORE_REG itself has nothing to do with memory usage.
And moreover, the conclusion below is not changed at all.

Thanks,
rin


IMO, in order to support VFP-register aliasing, we need to heavily modify
MI codes. This adds complexities to the code, and only ARM would receive
benefits from them.

Existing code was not acceptable for me; for example, GDB aborted *every
time* exceptions were raised. I won't revert this change at the moment.
Please provide working alternative if you don't like mine.

Thanks,
rin



Joerg



Re: CVS commit: src/sys/lib/libunwind

2021-05-31 Thread Rin Okuyama

On 2021/05/31 23:35, Joerg Sonnenberger wrote:

On Mon, May 31, 2021 at 12:12:24PM +, Rin Okuyama wrote:

Bump LAST_REGISTER and LAST_RESTORE_REG to REGNO_ARM32_S31 for arm.


This is not desirable as it significantly increases the memory use.
The goal here is to actually alias the single and double register in the
space. That's what the existing was doing.


Existing code did not.

With LAST_REGISTER = REGNO_ARM32_D31, libunwind gave up unwinding frames
when it encounters s0-s31; see parseInstructions():

https://nxr.netbsd.org/xref/src/sys/lib/libunwind/DwarfParser.hpp#parseInstructions

And with LAST_RESTORE_REG = REGNO_ARM32_D31, it did not copy-back contents
of s0-s31 at all; see stepWithDwarf():

https://nxr.netbsd.org/xref/src/sys/lib/libunwind/DwarfInstructions.hpp#136

IMO, in order to support VFP-register aliasing, we need to heavily modify
MI codes. This adds complexities to the code, and only ARM would receive
benefits from them.

Existing code was not acceptable for me; for example, GDB aborted *every
time* exceptions were raised. I won't revert this change at the moment.
Please provide working alternative if you don't like mine.

Thanks,
rin



Joerg



Re: CVS commit: src/sys/lib/libunwind

2021-05-31 Thread Rin Okuyama

On 2021/05/31 23:32, Joerg Sonnenberger wrote:

On Mon, May 31, 2021 at 12:12:24PM +, Rin Okuyama wrote:

There are two numbering schemes for VFPv2 registers: s0-s31 and d0-d15.
The former is used by GCC, and the latter is by LLVM. Since libunwind was
derived from LLVM, it has never supported the former. This results in
crashes for GCC-compiled binaries in exception handler of C++, if it
encounters VFPv2 registers when unwinding frames.


This is only half correct. GCC actually switched at some point.


I don't think so.

At least, when they supported VFPv3 back to 2009:

https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=854b8a40570fee8d8c22acf21355a8ab88f17557

and when they introduced arm_dbx_register_number(), which converts b/w
internal/DWARF regnum, back to 2005:

https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=2fa330b29a650365d4d88e4407fdbc2934dcb1b4

they used s0-s31 numbering for d0-d15.

More accurately, I *imagine*, GCC actually switched at some point to use
VFP registers for general purposes (mainly as cache for stack variables
for -O2, as far as I can see). Before this switch, only applications
using floating-point arithmetic were affected. But, after that, most
C++ applications became affected, and the problem got visible to us.

Thanks,
rin



Joerg



Re: CVS commit: src/sys/lib/libunwind

2021-05-31 Thread Rin Okuyama

On 2021/05/31 23:30, Joerg Sonnenberger wrote:

On Mon, May 31, 2021 at 11:41:22AM +, Rin Okuyama wrote:

Module Name:src
Committed By:   rin
Date:   Mon May 31 11:41:22 UTC 2021

Modified Files:
src/sys/lib/libunwind: Registers.hpp unwind_registers.S

Log Message:
...

- Introduce enum for flags.


Please undo this part. enums should *not* be used for flags.


Done. Thanks for pointing it out.

rin



Joerg



Re: CVS commit: src/sys/lib/libunwind

2021-05-31 Thread Joerg Sonnenberger
On Mon, May 31, 2021 at 12:12:24PM +, Rin Okuyama wrote:
> Bump LAST_REGISTER and LAST_RESTORE_REG to REGNO_ARM32_S31 for arm.

This is not desirable as it significantly increases the memory use.
The goal here is to actually alias the single and double register in the
space. That's what the existing was doing.

Joerg


Re: CVS commit: src/sys/lib/libunwind

2021-05-31 Thread Joerg Sonnenberger
On Mon, May 31, 2021 at 12:12:24PM +, Rin Okuyama wrote:
> There are two numbering schemes for VFPv2 registers: s0-s31 and d0-d15.
> The former is used by GCC, and the latter is by LLVM. Since libunwind was
> derived from LLVM, it has never supported the former. This results in
> crashes for GCC-compiled binaries in exception handler of C++, if it
> encounters VFPv2 registers when unwinding frames.

This is only half correct. GCC actually switched at some point.

Joerg


Re: CVS commit: src/sys/lib/libunwind

2021-05-31 Thread Joerg Sonnenberger
On Mon, May 31, 2021 at 11:41:22AM +, Rin Okuyama wrote:
> Module Name:  src
> Committed By: rin
> Date: Mon May 31 11:41:22 UTC 2021
> 
> Modified Files:
>   src/sys/lib/libunwind: Registers.hpp unwind_registers.S
> 
> Log Message:
> ...
> 
> - Introduce enum for flags.

Please undo this part. enums should *not* be used for flags.

Joerg