A lot of game engines (and other multithreaded apps) have some concept of a job system/threadpool.
It's always been inconvenient to step through code that uses those systems because the function call that "adds" the job/task is usually separate in time from when the actual task/job function is run.
It would be really nice to maybe expose a similar thing to type views/rules, but for stepping.
A way to say "for this function(s), modify the step behavior according to some user-defined rule or data or something"
Vague mockup:
steprule: "PushAJob" breakpoint@funcptr(params[1])
The meat & potatoes of this feature for the debugger to be able to place a breakpoint at runtime in a function given a function ptr
I'm not sure the best way to design the UX around that.
I.E.
void MyJob(jobCtx* ctx);
// No way to "step into" MyJob without navigating in debugger to the file with that function, then manually placing breakpoint in it.
PushAJob(jobSystemCtx, MyJob);
A rules system like this is too complicated for this non-critical problem.
So, another maybe simpler solution here is to allow right-click context menu in a code window to detect what it clicked on (function, parameter, local variable, etc) and if you right-click a hardcoded function name/ptr like MyJob above, one of the context menu options is "place breakpoint in this function".
That wouldn't handle a case where the function ptr the jobsystem is running is discovered at runtime, but maybe would still cover most use cases?
A lot of game engines (and other multithreaded apps) have some concept of a job system/threadpool.
It's always been inconvenient to step through code that uses those systems because the function call that "adds" the job/task is usually separate in time from when the actual task/job function is run.
It would be really nice to maybe expose a similar thing to type views/rules, but for stepping.
A way to say "for this function(s), modify the step behavior according to some user-defined rule or data or something"
Vague mockup:
steprule: "PushAJob" breakpoint@funcptr(params[1])The meat & potatoes of this feature for the debugger to be able to place a breakpoint at runtime in a function given a function ptr
I'm not sure the best way to design the UX around that.
I.E.
A rules system like this is too complicated for this non-critical problem.
So, another maybe simpler solution here is to allow right-click context menu in a code window to detect what it clicked on (function, parameter, local variable, etc) and if you right-click a hardcoded function name/ptr like MyJob above, one of the context menu options is "place breakpoint in this function".
That wouldn't handle a case where the function ptr the jobsystem is running is discovered at runtime, but maybe would still cover most use cases?