arch/xtensa: initial support for debugpoint api

[chirping78]

Summary

Implement up_debugpoint_add/up_debugpoint_remove for xtensa.

Impact

Can use debugpoint program to test code and data debugpoint.

Currently the int handler here will call panic when the debugpoint hit, will improve the int handler with following PR.

Update 25/03/03: Have complete the debug int handler. When the debug interrupt is triggered, it will call the registered callback.

Testing

enable CONFIG_LIB_GDBSTUB CONFIG_SYSTEM_DEBUGPOINT and disable CONFIG_NSH_DISABLE_MW to test.

Take esp32-devkitc:ostest as an example:

1. test breakpoint

$ grep cmd_ls System.map 
400e95c8 T cmd_ls

nsh> debugpoint -b 0x400e95c8                                                                                                                                                 
Debug point successfully added at address: 0x400e95c8                                                                                                                         
nsh> ls                                                                                                                                                                       
debug_callback_cmd: type=4 addr=0x400e95c8 size=0                                                                                                                             
/:                                                                                                                                                                            
 dev/                                                                                                                                                                         
 proc/                                                                                                                                                                        
nsh>

2. test watchpoint

$ grep g_version System.map 
3ffb2cdc d g_version

nsh> debugpoint -r 0x3ffb2cdc                                                                                                                                                 
Debug point successfully added at address: 0x3ffb2cdc                                                                                                                         
nsh> mw 3ffb2cdc                                                                                                                                                              
debug_callback_cmd: type=1 addr=0x3ffb2cdc size=4                                                                                                                             
  0x3ffb2cdc = 0x63633433                                                                                                                                                     
nsh> 

3. run debugpoint w/o argument

nsh> debugpoint
Testing breakpoints
==== Calling test_function ====
Add breakpoint at 0x400f1d98
Calling test_trigger
Pass: Breakpoint at 0x400f1d98 triggered
==== Calling test_data ====
Add read watchpoint at 0x3f4130bc
Pass: Read watchpoint at 0x3f4130bc triggered
==== Calling test_data ====
Add read watchpoint at 0x3ffb1fc1
Pass: Read watchpoint at 0x3ffb1fc1 triggered
==== Calling test_data ====
Add write watchpoint at 0x3ffb1fc1
Pass: Write watchpoint at 0x3ffb1fc1 triggered
==== Calling test_data ====
Add read/write watchpoint at 0x3ffb1fc1
Pass: Read watchpoint at 0x3ffb1fc1 triggered
Pass: Write watchpoint at 0x3ffb1fc1 triggered

[nuttxpr]

[Experimental Bot, please feedback here]

Yes, this PR appears to meet the basic NuttX requirements, but it's incomplete. Here's a breakdown:

Strengths:

• Clear Summary: The summary adequately describes the what and why of the change. The how could be slightly more explicit, perhaps mentioning the specific implementation details (e.g., register manipulation, interrupt handling).
• Impact Description: The impact section identifies the affected area (debugpoint functionality) and notes a planned future improvement for the interrupt handler.
• Testing Instructions: It provides basic testing instructions, including necessary configuration options.

Weaknesses:

• Missing Links: The summary mentions a future PR for improving the interrupt handler but doesn't provide a link or issue number.
• Incomplete Testing: The "Testing logs before change" and "Testing logs after change" sections are empty. This is critical and must be filled in with actual logs demonstrating the change's functionality and verifying it works as expected.
• Lack of Detail in Impact: While the impact section mentions changes to the user experience (ability to use the debugpoint program) and build process (config options), it lacks specifics. For instance, it doesn't mention which Xtensa architectures or boards were tested. The impact on documentation is also unclear — will documentation need to be updated to reflect this new functionality?
• Missing Build/Host Information: The testing section lacks details about the build host and target used for verification. Provide the requested OS, CPU, compiler, Xtensa architecture, board, and configuration.
• Security/Compatibility Impacts: The PR mentions no considerations for security or compatibility, which should be addressed, even if the impact is "NO". Explicitly stating "NO" with a brief justification (e.g., "NO - This change only affects debugging functionality and doesn't introduce new security risks.") is better than leaving it blank.

Conclusion:

While the PR presents a good starting point, it needs further work to fully meet the NuttX requirements. Specifically, it needs to include actual testing logs, complete information about the testing environment, and address the missing details in the Impact section. Adding the missing link to the planned interrupt handler PR would also be beneficial.

[tmedicci]

Hi @chirping78 , nice job!

Can you please improve the testing section on how to run the gdbstub and how to test it using a real HW? Also, being a new feature, can you please provide the related documentation?

[acassis]

@chirping78 @tmedicci does it require updating the Documentation/ ?

[chirping78]

Can you please improve the testing section on how to run the gdbstub and how to test it using a real HW?

Currently only debugpoint command is supported. Add breakpoint/watchpoint programmatically should also be supported.

To support gdbstub need more effort.

Also, being a new feature, can you please provide the related documentation?

debugpoint is already documented in Documentation/applications/system/debugpoint/index.rst

[chirping78]

@chirping78 @tmedicci does it require updating the Documentation/ ?

As said above, currently only debugpoint command is supported.
And debugpoint is already documented in Documentation/applications/system/debugpoint/index.rst.

[jerpelea]

please update commit title to
arch/xtensa: initial support for debugpoint api

[tmedicci]

Tried on ESP32-S3-DevKitC-1 board too.

[chirping78]

@acassis @jerpelea @tmedicci @xiaoxiang781216 Would you please merge this PR?

[tmedicci]

Thanks for submitting it, @chirping78!