Add support for Scrutiny Debugger (gsoc '26)

Programs Google Summer of Code
1

Hey all, I’m interesting in pursuing this topic (Issue #5333) for my gsoc proposal and as far as I can see, there are no other posts about this topic yet, so I’m opening this discussion.

So far, I was able to cross-compile & build the scrutiny debugger instrumentation library (repo here) with RTEMS:

[~/scrutiny-embedded/build-rtems] 𝛌 sparc-rtems7-objdump -f $HOME/scrutiny-embedded/build-rtems/lib/libscrutiny-embedded.a | head -20
In archive /home/aftwa/scrutiny-embedded/build-rtems/lib/libscrutiny-embedded.a:

scrutiny_main_handler.cpp.obj:     file format elf32-sparc
architecture: sparc, flags 0x00000011:
HAS_RELOC, HAS_SYMS
start address 0x00000000

I was also able to get a demo test file running on RTEMS via the sparc/erc32 architecture that successfully utilized the scrutiny library. The demo file initializes the scrutiny::MainHandler & config object inside an rtems init:

[~/gsoc/quick-start/src/rtems] 𝛌 sparc-rtems7-nm $HOME/gsoc/scrutiny_demo.exe | grep -i "scrutiny" | head -5
0204aa00 b _ZL15scrutiny_config
0204a690 b _ZL16scrutiny_handler
02006c24 W _ZN8scrutiny10IPCMessageINS_11LoopHandler16Loop2MainMessageEE3popEv
02007334 W _ZN8scrutiny10IPCMessageINS_11LoopHandler16Loop2MainMessageEE4sendERKS2_
02006c7c W _ZN8scrutiny10IPCMessageINS_11LoopHandler16Loop2MainMessageEE5clearEv

[~/gsoc/quick-start/src/rtems] 𝛌 rtems-run --rtems-bsp=erc32-sis $HOME/gsoc/scrutiny_demo.exe
RTEMS Testing - Run, 7.0.not_released

 Command Line: /home/aftwa/gsoc/quick-start/rtems/7/bin/rtems-run --rtems-bsp=erc32-sis /home/aftwa/gsoc/scrutiny_demo.exe
 Host: Linux aftwasiq 5.15.167.4-microsoft-standard-WSL2 #1 SMP Tue Nov 5 00:21:55 UTC 2024 x86_64
 Python: 3.12.3 (main, Jan 22 2026, 20:57:42) [GCC 13.3.0]

Host: Linux-5.15.167.4-microsoft-standard-WSL2-x86_64-with-glibc2.39 (Linux aftwasiq 5.15.167.4-microsoft-standard-WSL2 #1 SMP Tue Nov 5 00:21:55 UTC 2024 x86_64 x86_64)



 SIS - SPARC/RISCV instruction simulator 2.30,  copyright Jiri Gaisler 2020

 Bug-reports to jiri@gaisler.se



 ERC32 emulation enabled



 Loaded /home/aftwa/gsoc/scrutiny_demo.exe, entry 0x02000000

Scrutiny handler initialized & working on sparc/erc32



Time-out limit reached

Interrupt!

 Stopped at time 5600000000 (400000.000 ms)

Run time     : 0:00:04.068734

This all shows that the scrutiny instrumentation library can be built, linked, and executed on RTEMS without toolchain issues or errors.

Given that this is a porting effort, I would say that the next (big) step would be writing an RSB recipe for scrutiny embedded. If any potential mentors have some sort of idea of the general scope of what should be integrated, that would be helpful. In specific, whether targetting a minimal RSB package with one protocol like UART, or if it should branch out to other protocols (all within the scope of a medium-level gsoc?)

I’m still branching out the structure for my proposal, so any guidance or advice would be greatly appreciated.

2

I would target the bare minimum at first. UART sounds like a great idea since that’s supported by mostly everything. Down the road networking would be nice for OTA but not every BSP has access to that and really, for debugging it’s not required.

There are two main options in doing this. Add it as a package such as rtems-scrutiny or add it to RTEMS itself depending on what’s involved. The actual linked library should be added to the RSB while the frontend would be left to the user to figure out.

You shouldn’t need to modify RTEMS at all to add this support so going the package route + RSB for the library makes the most sense.

3

Thanks! I agree that adding networking/OTA capabilities is reasonably beyond the scope of the current project. So far I’m thinking that the rough structure of the proposal should follow: RSB recipe → packaged as rtems-scrutiny → UART transport → demo & documentation → confirming its usage on several BSPs. Whether or not to pursue the packaging option is still something I’m looking into, but it’ll most likely be the option that makes the most sense.

UART integration through the termios interface would be more than sufficient, unless I need to go lower-level for some reason which I heavily doubt will happen. The specified stats (memory total, CPU total, device I/O, interrupts, and more) would be chosen on the frontend by the user. Of course, in the demonstration component, there would be tutorials for the basics of each of them & how to monitor them.

4

Another thing I wanted to add on was the possibility of incorporating a CAN bus transport? Scrutiny states the following native transports: serial (UART), CAN, & an IP stack. Given that an IP stack is too broad and many BSPs don’t support it, instead we can opt to also include a CAN transport as a second/potential deliverable with a UART transport as the primary. Let me know what you think.

5

Update:

I’ve begun working on a basic package (.cfg and .bset files) under rtems-scrutiny in my fork, referencing the fmt and yaml packages under devel/ as a rough guide. I also want to emphasize on a quick summary of my proposed workflow so far here (which is expanded on more in depth in my proposal thats linked below), because I’ve significantly changed the deliverables that I initially proposed earlier in this thread.

So far,
a working RSB recipe & package → working UART transport that reads & writes over RTEMS termios layer → working instrumentation configuration (hooking up scrutiny to the RTEMS clock, buffer allocation, etc) → integration of Scrutiny functions for datalogging firmware information → user front api that abstracts information for configuration that the user wants to include (which transport, metrics, etc)

I’ve pretty much fleshed out the components for how I’m going to approach this project. This is mainly based on my own research so I am worried if I could potentially be heading in the wrong direction. I’ve laid everything out (so far) in my proposal here if the potential mentors for this project (@wmthornton-dev, @kiwichris) want to check it out and offer advice. Sending an MR aswell so it’ll be available on my tracking page.

I have a couple questions for anyone following along:
Would rtems-scrutiny need its own testsuites?
Possibility on a CAN bus implementation beyond UART (details on my earlier comments)?

6

I would not pursue the CAN bus transport at this time.

You should definitely think about how to test the capabilities.

1 Like