RTEMS | cpukit: reformat libdebugger (!983)

[Chris Johns (@chris)]

Merge request https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/983 was reviewed by Chris Johns

--
  
Chris Johns started a new discussion on cpukit/libdebugger/rtems-debugger-arm.c: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/983#note_141856

 > +                                                        used */                \
 > +                   "movw  r2, #:lower16:debug_registers\n" /* get the debug    \
 > +                                                              regs */          \

Shame the comments here are now not on a single line. This is difficult assembler so I hope it is still readable. What do you think?

--
  
Chris Johns started a new discussion on cpukit/libdebugger/rtems-debugger-arm.c: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/983#note_141857

 > +                                       ARM_HW_BP_UNLOAD(                       \
 > +                                           15) "3:\n" ARM_DGB_ENABLE_INTS      \
 > +                                               "4:\n" ARM_SYNC_INST            \

This looks wrong and I do not think this works?

--
  
Chris Johns started a new discussion on cpukit/libdebugger/rtems-debugger-arm.c: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/983#note_141858

 > +#define EXCEPTION_ENTRY_DEBUGGER()                                             \
 > +  __asm__ volatile(/* Set up r0 and r1 */                                      \
 > +                   "movw  r0, #:lower16:hw_breakpoints\n" /* get the num hw    \

I wonder if the indent to the `(` is causing the alignment to move to the right? The `EXCEPTION_ENTRY_THREAD` macro is not doing that,I wonder why the difference?

--
  
Chris Johns started a new discussion on cpukit/libdebugger/rtems-debugger-arm.c: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/983#note_141859

 > +                                                       checks */               \
 > +                          "msr  cpsr, r1\n" /* restore the state with irq mask \
 > +                                               clear */                        \

Not sure the formatter is handling the macros in the asm code?

--
  
Chris Johns started a new discussion on cpukit/libdebugger/rtems-debugger-arm.c: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/983#note_141860

 > +          frame_fpu_size) "ldr  r2, [sp, %[frame_cpsr]]\n" /* recover exc CPSR \
 > +                                                              from thread */   \
 > +                          "mov  r0, sp\n"   /* get the thread frame pointer */ \

And again here?

--
  
Chris Johns started a new discussion on cpukit/libdebugger/rtems-debugger-arm.c: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/983#note_141861

 > +  __asm__ volatile(/* Set up r0, r1, r4 and r5 */                              \
 > +                   "movw  r0, #:lower16:hw_breakpoints\n" /* get the num hw    \
 > +                                                             breaks */         \

And here

--
  
Chris Johns started a new discussion on cpukit/libdebugger/rtems-debugger-arm.c: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/983#note_141862

 > +                       ARM_HW_BP_LOAD(1) ARM_HW_BP_LOAD(2) ARM_HW_BP_LOAD(     \
 > +                           3) ARM_HW_BP_LOAD(4) ARM_HW_BP_LOAD(5)              \
 > +                           ARM_HW_BP_LOAD(6) ARM_HW_BP_LOAD(7) ARM_HW_BP_LOAD( \

And here

--
  
Chris Johns started a new discussion on cpukit/libdebugger/rtems-debugger-i386.c: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/983#note_141863

 >  static const char* const target_xml =
 > -"<?xml version=\"1.0\">                        \
 > +    "<?xml version=\"1.0\">                        \

Why add the space?


-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/983
You're receiving this email because of your account on gitlab.rtems.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20260205/89dcb9fd/attachment-0001.htm>