|
04:32
rakkable left
04:33
rakkable joined
10:40
japhb left
10:44
japhb joined
10:48
Geth left,
Geth joined
10:49
Geth joined
10:52
japhb joined,
rakkable joined,
[Coke] joined,
leont joined,
benchable6__ joined,
coverable6__ joined,
sourceable6__ joined,
linkable6__ joined,
tellable6__ joined,
vrurg joined,
Techcable joined,
ShimmerFairy joined,
disbot2 joined,
kjp joined,
sugarbeet joined,
Sario joined,
xiaomiao joined,
nine joined,
bisectable6 joined,
notable6 joined,
committable6 joined,
quotable6 joined,
greppable6 joined,
releasable6 joined,
shareable6 joined,
unicodable6 joined,
bloatable6 joined,
nativecallable6 joined,
evalable6 joined,
patrickb joined,
Voldenet joined,
rba joined,
JRaspass joined,
Guest693 joined,
jjatria joined,
jnthn joined,
ab5tract joined,
SmokeMachine joined,
gfldex joined,
timo joined,
tbrowder joined,
ingy joined,
harrow joined,
camelia joined,
ilogger2 joined,
jdv joined
|
|||
| patrickb | I just realized: `notify_new_file` is called from `MVM_debugserver_register_line` which in turn is called from spesh during bytecode instrumentation. I'm a bit unsure where the next GC safepoint is during bytecode instrumentation, but I would guess that it's not in the file that is currently instrumented. | 10:58 | |
| timo | oh, inside spesh? that could be related to speculatively inlining code that hasn't been speshed yet | 10:59 | |
| that's not very good, but I assume it will happen outside of the spesh thread in many more cases | |||
| patrickb | Which makes me think: Maybe a better place to start looking for $?CHECKSUM and $?SOURCE would be in `MVM_debugserver_breakpoint_check`, i.e. the instrumentation function. | 11:00 | |
| The above realization is not based on looking at stracktraces. I just looked at the code. The only caller chain of `notify_new_file` is the one coming from instrument/line_coverage.c, i.e. the part where the breakpoint instruction is injected into the bytecode. | 11:02 | ||
| Idea: Add a `first_call` flag to MVMDebugServerBreakpointFileTable, check for that flag in `MVM_debugserver_breakpoint_check`, instantly set it to false and suspend there. This is equivalent to just breaking on the first possible breakposition in the new file. | 11:08 | ||
| I think for the purposes of the file notification request, having the suspend how it currently is might be fine. So I tend to add the ability of such a initial break funtionality separately. | 11:12 | ||
| timo | ah, ok, instrument/line_coverage.c should be called from the instrumentation barrier which gets checked when a code is invoked and its internal instrumentation level differs from the mvminstance's instrumentation level, which is normally increased if you turn profiling on for example | 11:14 | |
| i wouldn't call MVM_debugserver_breakpoint_check "the instrumentation function" but that's a minor nitpick | 11:16 | ||
| patrickb | Idea: add a boolean flag: `initial` to MT_SetBreakpointRequest, require that `suspend` is also set and no line number is given. When that is set, break on every possible break position in that file. Only when that thread is resumed will the `first_call` flag be reset. This will also solve the issue of concurrent other threads also running code in that file. | 11:17 | |
| timo | the "first_call" idea is not bad. maybe it will also enable us to make any thread stop when hitting it until the thread that first hit it was unsuspended, too | ||
| to prevent the issue where if many threads run "towards" the new file, only one gets stopped and all others can just run past | 11:18 | ||
| patrickb | Exactly | ||
| Do you think I have a chance to make this change? | 11:25 | ||
| timo | IMO, making this enhanced functionality "replace" how it is currently implemented is a good idea, there's no need for an additional feature or flag in messages or things like that | 11:26 | |
| though a "file-wide breakpoint" could be interesting separately from this too | |||
| did i just contradict myself over the course of five seconds? | 11:27 | ||
| lizmat | did you? | 11:28 | |
| patrickb | Hm. What's the difference of a file wide breakpoint and the hypothetical new notify_new_file behavior? | 11:42 | |
| If it's only that the new notify_new_file auto-removes the breakpoint on resume, then I'd say let's not have the notify_new_file thing at all. | 11:43 | ||
| Hm... When new file notification is active it'll have to add that file file wide breakpoint automatically on every new file. | 11:44 | ||
| So the only thing the file notification thing does is auto adding a file wide breakpoint on every file load. The client would then always receive two responses, 1. a breakpoint_set response directly followed by a 2. breakpoint_hit response. | 11:47 | ||
| I'd want to add a `file` attribute to MT_SetBreakpointConfirmation. Otherwise users will have no idea which new file the response belongs to. | 11:49 | ||
| The `id` would be the one of the file notification request. A new `breakpoint_id` field would hold the ID of that new breakpoint. | 11:50 | ||
| Does the above sound sound | |||
| ? | |||
| timo | sounds reasonable, yeah. the "automatically create a breakpoint whenever any new file is seen" behaviour is definitely useful aside from setting a file-wide breakpoint for a file you already know about | 12:02 | |
| the "clear the breakpoint after the thread that initially saw it resumes" behaviour doesn't have to go into moarvm. in fact, it may be annoying if the VM behaves like that when you don't want it, so it should probably be something the debugserver client does explicitly | 12:13 | ||
| I recently thought that we may want a command for the debugserver that uses the heapsnapshot "describe" function in the REPRs to get a list of all outgoing references from any object, so that you can also get at WHO and friends without a bunch of extra special commands | 12:14 | ||
|
15:00
librasteve_ joined
|
|||
| librasteve_ | rakudoweekly.blog/2026/03/23/2026-...-berliner/ | 19:21 | |
| lizmat | librasteve_++ | 19:50 | |
|
23:15
kjp left
|
|||