Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix: cortexar hardware breakpoints #1894

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

litui
Copy link
Contributor

@litui litui commented Aug 14, 2024

Detailed description

  • Hardware breakpoints are now working by bypassing the MMU at the top of the virt_to_phys function when an address is located in RAM. Without this bypass, RAM addresses were being mangled due to inaccurate phys_addr being supplied by the address translation machinery.
  • Overriding soft breakpoints to hard breakpoints because GDB automatically selects soft breakpoints when a) a memory map xml is provided, and b) the address is located in RAM. This is not incorrect behaviour, but an override is necessary unless/until soft breakpoints are implemented for cortexar on BMP.

Your checklist for this pull request

Closing issues

@litui litui changed the title cortexar: pc set correctly?, hard breakpoints working in RAM Feature/Fix?: cortexar hardware breakpoints and resume from halt after load Aug 14, 2024
@litui litui changed the title Feature/Fix?: cortexar hardware breakpoints and resume from halt after load WIP: Feature/Fix?: cortexar hardware breakpoints and resume from halt after load Aug 14, 2024
@litui litui force-pushed the fix/cortexar-resume-after-load branch 3 times, most recently from c1f721b to fc57ee5 Compare August 15, 2024 09:02
@litui litui changed the title WIP: Feature/Fix?: cortexar hardware breakpoints and resume from halt after load WIP: Fix: cortexar hardware breakpoints Aug 15, 2024
@litui
Copy link
Contributor Author

litui commented Aug 15, 2024

There, more or less fixed things back to the way I found them with the exception of the RAM address fix. Tested and continuation from a load works, and breakpoints appear to land in the correct places with the check of the address against the RAM. Will look over it all again tomorrow when I'm awake.

@litui litui changed the title WIP: Fix: cortexar hardware breakpoints Fix: cortexar hardware breakpoints Aug 15, 2024
@litui
Copy link
Contributor Author

litui commented Aug 16, 2024

@litui litui force-pushed the fix/cortexar-resume-after-load branch from 8c72787 to a11fd2b Compare August 31, 2024 18:33
@litui
Copy link
Contributor Author

litui commented Sep 1, 2024

This PR will need tweaking after #1916 gets merged in.

Edit: done!

@litui litui force-pushed the fix/cortexar-resume-after-load branch from a11fd2b to b961e13 Compare September 1, 2024 22:03
@litui
Copy link
Contributor Author

litui commented Sep 2, 2024

I bumped a request on cortex-debug's repo ( Marus/cortex-debug#978 ) for ability to set the break command used in gdb and then stumbled upon a comment in Marus/cortex-debug#555 which noted that OpenOCD, as a gdb server backend, offers the command gdb_breakpoint_override. Setting this override up as a BMP monitor command might be something to think about.

@litui litui force-pushed the fix/cortexar-resume-after-load branch 3 times, most recently from af8c811 to 956a3a8 Compare September 2, 2024 20:26
* As software breakpoints are not yet implemented, force hard breakpoints on cortexar targets
@litui litui force-pushed the fix/cortexar-resume-after-load branch from 956a3a8 to 805f8f0 Compare September 2, 2024 20:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant