Making it easier to work with shaders https://git.yummers.dev/slang.git/atom?h=master 2025-08-18T15:29:57+00:00 2025-08-18T15:29:57+00:00 Sam Estep sam@samestep.com 2025-08-18T15:29:57+00:00 urn:sha1:d9851d4e45d2344e0e220ef6199ef4e117066f0f This is a followup on #7828 to fix bugs that were causing CodeLLDB to give wrong values and hang (see vadimcn/codelldb#1302) because I didn't realize that these data formatters can be passed _either_ a value of a given type _or_ a pointer to a value of that type, and need to handle both cases. I also introduced loop bounds to prevent hangs in the case where these synthetic values are constructed for things like uninitialized variables. From looking at the preexisting data formatters from #4272 in `source/core/core_lldb.py`, it seems like they _technically_ have similar bugs to this, but since those types are simpler, it's unclear to me whether that can actually manifest in meaningful ways like these bugs in `source/slang/slang_lldb.py` were doing. Anyways, to test this, put a breakpoint here: https://github.com/shader-slang/slang/blob/6d399804a353154259cf4410940f144db8f9b5cf/source/slang/slang-emit-cpp.cpp#L1733 And use this `.vscode/launch.json` for CodeLLDB: ```json { "version": "0.2.0", "configurations": [ { "name": "LLDB", "preLaunchTask": "Debug build", "type": "lldb", "request": "launch", "initCommands": ["command source .lldbinit"], "program": "build/Debug/bin/slangc", "args": [ "tests/cpu-program/cpu-hello-world-test.slang", "-target", "executable", "-o", "hello" ] } ] } ``` Before this PR, the `inst` variable will display in the debug pane as `{kIROp_StringLit 0x00007fffffff5f68}`, which is the wrong pointer value. You can also check this by running `p inst` in the Debug Console, which will print this: ``` (Slang::IRInst *) 0x000055555fdac3b8 {kIROp_StringLit 0x00007fffffff5f68} ``` In contrast, running `p *inst` prints the correct pointer value: ``` (Slang::IRInst) {kIROp_StringLit 0x000055555fdac3b8} { [op] = kIROp_StringLit [UID] = 76 [type] = 0x000055555fdac348 {kIROp_StringType None} [decorations/children] = {} [parent] = 0x000055555fdac2d0 {kIROp_ModuleInst None} [uses] = 0x000055555fdadf18 {kIROp_StringLit 0x000055555fdac3b8} } ``` But as you can see, in that case the synthetic `[value]` child is completely missing. Then if you try to expand `inst` in the debug pane, CodeLLDB will hang (or at least it does when I try this). After this PR, the hex integer for the pointer is always consistent, and CodeLLDB does not hang in the debug pane when you expand `inst`, and shows the correct `[value]` child just like when running `v *inst`. As an aside: after this PR, the `[value]` child is still missing when specifically running `p *inst` in the Debug Console. It _is_ possible to fix this: ```diff diff --git a/source/slang/slang_lldb.py b/source/slang/slang_lldb.py index 23905d8c5..d2b3a4da9 100644 --- a/source/slang/slang_lldb.py +++ b/source/slang/slang_lldb.py @@ -93,13 +93,11 @@ class IRInst_synthetic(lldb.SBSyntheticValueProvider): value: list[tuple[str, lldb.SBValue]] = [] match op.value: case "kIROp_StringLit": - string_lit_t = target.FindFirstType("Slang::IRStringLit") - string_lit = self.valobj.Cast(string_lit_t) + string_lit = self.valobj.EvaluateExpression("(Slang::IRStringLit*)this") val = string_lit.GetChildMemberWithName("value") value = [("[value]", val.GetChildMemberWithName("stringVal"))] case "kIROp_IntLit": - int_lit_t = target.FindFirstType("Slang::IRIntLit") - int_lit = self.valobj.Cast(int_lit_t) + int_lit = self.valobj.EvaluateExpression("(Slang::IRIntLit*)this") val = int_lit.GetChildMemberWithName("value") value = [("[value]", val.GetChildMemberWithName("intVal"))] diff --git a/typings/lldb.pyi b/typings/lldb.pyi index 2672ba244..3a08e9141 100644 --- a/typings/lldb.pyi +++ b/typings/lldb.pyi @@ -496,7 +496,7 @@ class SBValue: def Persist(self): ... def GetDescription(self, description): ... def GetExpressionPath(self, *args): ... - def EvaluateExpression(self, *args): ... + def EvaluateExpression(self, expr: str) -> SBValue: ... def Watch(self, *args): ... def WatchPointee(self, resolve_location, read, write, error): ... def GetVTable(self): ... ``` However, that makes the debugger run _significantly_ slower, so I'm choosing not do do it here. --------- Co-authored-by: Ellie Hermaszewska <ellieh@nvidia.com> 2025-07-23T14:00:24+00:00 Sam Estep sam@samestep.com 2025-07-23T14:00:24+00:00 urn:sha1:876b21f21cb9bfdff1479364f60f2ce6b15ea0b3 2025-07-22T08:31:09+00:00 Sam Estep sam@samestep.com 2025-07-22T08:31:09+00:00 urn:sha1:e6906d65ed5367b46675f97b2a272a52c74b6806