-
-
Notifications
You must be signed in to change notification settings - Fork 775
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
base: main
Are you sure you want to change the base?
Conversation
c1f721b
to
fc57ee5
Compare
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. |
For testing purposes (for the Deluge crowd), here are a couple launch.json configs for VSCode and here is the meson cross-file I'm using to build blackmagic |
8c72787
to
a11fd2b
Compare
This PR will need tweaking after #1916 gets merged in. Edit: done! |
a11fd2b
to
b961e13
Compare
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 |
af8c811
to
956a3a8
Compare
* As software breakpoints are not yet implemented, force hard breakpoints on cortexar targets
956a3a8
to
805f8f0
Compare
Detailed description
virt_to_phys
function when an address is located in RAM. Without this bypass, RAM addresses were being mangled due to inaccuratephys_addr
being supplied by the address translation machinery.Your checklist for this pull request
Closing issues