Jeremy Lorelli commented on a discussion on cpukit/libdebugger/rtems-debugger-target.c: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1275#note_151426 > rtems_debugger_target* target = rtems_debugger->target; > Thread_Control* thread = _Thread_Get_executing(); > const rtems_id tid = thread->Object.id; > - rtems_debugger_thread fake_debugger_thread; > + rtems_debugger_thread fake_debugger_thread = {}; This was highlighted by clangd as I was debugging something unrelated in libdebugger. Thanks for pointing out that `= {};` is a GNU extension, I will change it to `= {0};` `rtems_debugger_thread` is a fairly small structure (36-bytes on 32-bit architectures), but yeah the compiler generated memset will add some cycles here. After looking at it more, I don't think it's a huge deal because `rtems_debugger_soft_step_and_continue` is not a hot path and only appears to be used in the handling of breakpoints. There are other uninitialized fields in this structure, including some pointers, that are passed down to architecture specific code implementing `rtems_debugger_target_thread_stepping` -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1275#note_151426 You're receiving this email because of your account on gitlab.rtems.org.
_______________________________________________ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
