SIS Simulator works standalone but fails with GDB debugging on GR740 - INTERNAL_ERROR_NO_MEMORY_FOR_HEAP

Hi everyone,

I’m having trouble debugging RTEMS applications using SIS simulator with GDB on GR740 emulation. The application runs fine when executed directly through SIS, but encounters memory allocation errors when using GDB.

Working scenario:

sparc-rtems7-sis -gr740 -nouartrx -r -m 4 src/rtems/build/sparc/gr740/testsuites/samples/hello.exe

This executes perfectly and shows the expected “Hello World” output like below:


 SIS - SPARC/RISCV instruction simulator 2.30,  copyright Jiri Gaisler 2020
 Bug-reports to jiri@gaisler.se

 GR740/LEON4 emulation enabled, 4 cpus online, delta 50 clocks

 Loaded src/rtems/build/sparc/gr740/testsuites/samples/hello.exe, entry 0x00000000


*** BEGIN OF TEST HELLO WORLD ***
*** TEST VERSION: 7.0.0.8fd021bbb30843dc91e5bac228b5d463b45530ae
*** TEST STATE: EXPECTED_PASS
*** TEST BUILD: RTEMS_DEBUG RTEMS_POSIX_API RTEMS_SMP
*** TEST TOOLS: 13.4.0 20250605 (RTEMS 7, RSB 3d1db73ef0de7cc396183f6c599a301f355d2bba, Newlib 038afec1)
Hello World

*** END OF TEST HELLO WORLD ***


[ RTEMS shutdown ]
CPU: 0
RTEMS version: 7.0.0.8fd021bbb30843dc91e5bac228b5d463b45530ae
RTEMS tools: 13.4.0 20250605 (RTEMS 7, RSB 3d1db73ef0de7cc396183f6c599a301f355d2bba, Newlib 038afec1)
executing thread ID: 0x0a010001
executing thread name: UI1 
cpu 0 in error mode (tt = 0x80)

Problematic scenario:

# Terminal 1: Start SIS with GDB server
sparc-rtems7-sis -gdb -gr740 -m 4

# Terminal 2: Connect with GDB
sparc-rtems7-gdb src/rtems/build/sparc/gr740/testsuites/samples/hello.exe
(gdb) target extended-remote localhost:1234
(gdb) load
(gdb) c

Error encountered:
When starting SIS with -gdb option (without specifying the executable), I get:

 SIS - SPARC/RISCV instruction simulator 2.30,  copyright Jiri Gaisler 2020
 Bug-reports to jiri@gaisler.se

 GR740/LEON4 emulation enabled, 4 cpus online, delta 50 clocks

gdb: listening on port 1234 connected
X0,0:#1e

*** FATAL ***
fatal source: 0 (INTERNAL_ERROR_CORE)
CPU: 0
fatal code: 23 (INTERNAL_ERROR_NO_MEMORY_FOR_HEAP)
RTEMS version: 7.0.0.8fd021bbb30843dc91e5bac228b5d463b45530ae
RTEMS tools: 13.4.0 20250605 (RTEMS 7, RSB 3d1db73ef0de7cc396183f6c599a301f355d2bba, Newlib 038afec1)
executing thread is NULL

X0,0:#1e appears to be the GDB remote response during the load operation.

Environment:

  • Target Platform: GR740 (LEON4 SPARC V8 quad-core processor)
  • SIS version: 2.30
  • RTEMS version: 7.0.0.8fd021bbb30843dc91e5bac228b5d463b45530ae
  • Toolchain: sparc-rtems7-gcc 13.4.0 20250605 (RTEMS 7, RSB 3d1db73ef0de7cc396183f6c599a301f355d2bba, Newlib 038afec1)
  • SIS Configuration: GR740/LEON4 emulation with 4 CPU cores (-gr740 -m 4)
  • Application: Simple “Hello World” test from RTEMS testsuites (built for sparc/gr740 BSP)
  • Memory Layout: Using GR740’s default memory configuration

RTEMS Build Environment:

Toolchain Installation:

../source-builder/sb-set-builder --prefix=/opt/rtems/7 7/rtems-sparc

RTEMS Kernel Configuration:

./waf configure --rtems-bsps=sparc/gr740 --rtems-tools=/opt/rtems/7 --prefix=/opt/rtems/7 --rtems-config=config.ini

Build and Install:

./waf && ./waf install

config.ini contents:

[sparc/gr740]
RTEMS_SMP=True
RTEMS_POSIX_API=True
BUILD_TESTS=True
RTEMS_DEBUG=True

Questions:

  1. Are there any GR740-specific or SMP-specific considerations for SIS debugging that I should be aware of?
  2. Does the debug build configuration (RTEMS_DEBUG=True) affect the debugging workflow with SIS?

Any insights on the proper workflow for debugging RTEMS applications with SIS on GR740, especially in SMP configurations, would be greatly appreciated!

Thanks in advance!

Thank you, I have opened an issue to look at this further: SIS Simulator works standalone but fails with GDB debugging on GR740 (#2) · Issues · RTEMS / Tools / SIS · GitLab

I have fixed this in interf: remove check for PC=0 for gdb_init (!9) · Merge requests · RTEMS / Tools / SIS · GitLab and hopefully we should be able to pick it up for rtems7 tools.

The RTEMS_DEBUG should not affect using a debugger. That enables some internal debug checks.