Potential ARC Metaware compiler bug with nsim/nsim_vpx5

[peter-mitsis]

Describe the bug

Executing the libraries.libc.sprintf testcase (tests/lib/sprint) results in an exception using the ARC MetaWare 1.2 toolchain when using the nsim/nsim_vpx5 board

Regression

• This is a regression.

Steps to reproduce

Using the ARC Metaware 1.2 toolchain ...

1. cd ${ZEPHYR_BASE}
2. west build -p -b nsim/nsim_vpx5 ./tests/lib/sprintf
3. nsimdrv -propsfile ./boards/snps/nsim/arc_classic/support/nsim_vpx5.props ./build/zephyr/zephyr.elf

Relevant log output

E: ***** Exception vector: 0x6, cause code: 0x2, parameter 0x2
E: Address 0x800038c3
E: EV_ProtV
E: Memory write protection violation (stack checking scheme)
E:  r0: 0x8  r1: 0x800038c3  r2: 0x80003872  r3: 0x8000387a
E:  r4: 0x0  r5: 0x0  r6: 0x5548  r7: 0x1
E:  r8: 0x86000  r9: 0x0 r10: 0x1f r11: 0x0
E: r12: 0x800038b4 r13: 0x80003162  pc: 0x26fc
E:  blink: 0x26f8 status32: 0x80086806
E: lp_end: 0x3c2 lp_start: 0x39a lp_count: 0x0
E: >>> ZEPHYR FATAL ERROR 2: Stack overflow on CPU 0
E: Current thread: 0x80002f04 (test_snprintf)
Caught system error – reason 2 0
Fatal error was unexpected, aborting...

Impact

Annoyance – Minor irritation; no significant impact on usability or functionality.

Environment

• OS: Linux
• Toolchain: ARC Metaware 1.2
• Commit: 9c1fbc8

Additional Context

1. Of the sampling of nsim boards that I have checked, this issue only replicates on the nsim/nsim_vpx5 .

2. The address at which I observed the failure to occur (0x26fc) corresponded to the following line in the disassembled output ...
   26fc: 00 19 03 00 stb 0,[%r1,0]

This in turn corresponds to the following line in lib/libc/minimal/source/stdout/sprintf.c::snprintf() ...
*(p.ptr) = 0;

3. The problem manifests when the size of the buffer passed to snprintf() is set to 0.
4. When printk() debugging statements are added to sprintf.c::sprintf(), the problem disappears and everything works--even if the only printk() is added AFTER *(p.ptr) = 0; . In this scenario the disassembled output shows that the stack is structured differently. This makes me suspect a potential compiler issue.