You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 22, 2020. It is now read-only.
For smaller devices that only provide two breakpoints the current approach might be problematic, because when using the test-lib, the _exit-code breakpoint and the syscalls (for gcov) in conjunction we already need three. There should be a way to remedy that and reduce them to one. The most obvious way is to add a METAL_BREAKPOINT macro. When compiled in unified mode (or whatever I'll call that) it enters a call to metal_trigger_breakpoint which exists ONCE in the binary and which contains the breakpoint. Then the debugger calls step-return and calls the breakpoint it's in.
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
For smaller devices that only provide two breakpoints the current approach might be problematic, because when using the test-lib, the _exit-code breakpoint and the syscalls (for gcov) in conjunction we already need three. There should be a way to remedy that and reduce them to one. The most obvious way is to add a
METAL_BREAKPOINT
macro. When compiled inunified
mode (or whatever I'll call that) it enters a call tometal_trigger_breakpoint
which exists ONCE in the binary and which contains the breakpoint. Then the debugger calls step-return and calls the breakpoint it's in.The text was updated successfully, but these errors were encountered: