The "threads disable" command is behaving inconsistently.
When using "threads disable" before the first resume, the command is ignored. This is in contrary to the command being described to be "manual control" for the "not perfect" logic of enabling reporting only after the first resume.
Expected: "monitor threads disable" disables thread reporting until "monitor threads enable"
But instead, since gdbserver.first_run_after_reset_or_flash is True, the manual action is ignored:
|
if self.first_run_after_reset_or_flash: |
|
self.first_run_after_reset_or_flash = False |
|
if self.thread_provider is not None: |
|
self.thread_provider.read_from_target = True |
I'm suggesting to change this behavior. Its unintuitiv that the manual action is silently ignored.
For now I solved this using a user script. But obviously, this is brittle, using internal, undocumented attributes and may become incompatible in the future. So this is not a final solution. I'm still leaving this here for anybody encountering the same issue:
@command(help="Prevent pyOCD from auto-enabling RTOS reads on the next first resume")
def clear_first_run(core: int = 0):
gdbserver = session.gdbservers[core]
gdbserver.first_run_after_reset_or_flash = False
print(f"core {core}: first_run_after_reset_or_flash cleared")
and instead of continue, call
monitor threads disable
monitor clear_first_run 0
continue
The "threads disable" command is behaving inconsistently.
When using "threads disable" before the first resume, the command is ignored. This is in contrary to the command being described to be "manual control" for the "not perfect" logic of enabling reporting only after the first resume.
Expected: "monitor threads disable" disables thread reporting until "monitor threads enable"
But instead, since gdbserver.first_run_after_reset_or_flash is True, the manual action is ignored:
pyOCD/pyocd/gdbserver/gdbserver.py
Lines 810 to 813 in ff767fe
I'm suggesting to change this behavior. Its unintuitiv that the manual action is silently ignored.
For now I solved this using a user script. But obviously, this is brittle, using internal, undocumented attributes and may become incompatible in the future. So this is not a final solution. I'm still leaving this here for anybody encountering the same issue:
and instead of
continue, call