[GR-44474] Windows Debug Information for local variables - prerequisite record definitions #5638

stooke · 2022-12-16T17:59:50Z

This PR implements issue #5635 by adding Windows CodeView records support to define local variables.

Method parameter variables (including 'this') are defined as a demonstration. No other local variable information is implemented by this PR as this PR is not aware of the lifetime of variables or stack frame information. Method parameter variables are available to the debugger only upon entry to a method.

There is a body of unused code (symbol record definitions) in this PR - it will be required for local variable definition in the followup PR.

...src/com.oracle.objectfile/src/com/oracle/objectfile/pecoff/cv/CVSymbolSubsectionBuilder.java

adinn

Sorry, I cannot comment on the correctness of the PECOFF record layouts or what CodeView expects. However, as far as use of the generic param info is concerned this looks ok.

pejovica · 2023-02-27T17:48:30Z

...src/com.oracle.objectfile/src/com/oracle/objectfile/pecoff/cv/CVSymbolSubsectionBuilder.java

        addLineNumberRecords(compiledEntry);
    }

+    void addLocals(CompiledMethodEntry primaryEntry) {


@stooke I was kind of expecting this code to at least make some use of the debug info location support added in #4505, but that doesn't seem to be the case. Is the functionality exposed via DebugLocalInfo (and friends) insufficient for this use case?

@pejovica this PR is a prerequisite to adding that support. This PR mostly implements the CodeView records required, and provides a quick but working proof of concept to examine register-based function parameters. A follow up PR will extend the functionality to use DebugLocalInfo, which was not available when this code was written.

@pejovica, I have modified this PR to use the actual parameter names instead of synthetic names (no more 'p1, 'p2', etc), which means this PR as is is fairly useful to Windows developers, which can now set a breakpoint at function start and examine parameters in the Visual Studio IDE. I have also merged the latest Graal head. Please have a look when you get the chance.

I continue to work on the follow-up PR, which will take full advantage of @adinn 's PR #4505.

…ows-varinfo

adinn · 2023-07-31T10:52:12Z

@pejovica Is there any reason why this PR has still not been integrated?

Simon (@stooke) has code already lined up that will use location info. However, that code is not included here because he was explicitly asked to implement the Windows behaviour in stages.

Can we please make progress on this PR which has been sitting waiting for a final review for months?

pejovica · 2023-08-09T13:19:21Z

@pejovica Is there any reason why this PR has still not been integrated?

Simon (@stooke) has code already lined up that will use location info. However, that code is not included here because he was explicitly asked to implement the Windows behaviour in stages.

Can we please make progress on this PR which has been sitting waiting for a final review for months?

@adinn Sorry about that. I was interrupted by other work and this PR unfortunately fell off the radar. However, it will need a bit more work before it can be integrated.

In particular, I don't think we should hardcode the same calling convention for all methods as is done in this PR because that is clearly incorrect. Instead, I think the logic in CVSymbolSubsectionBuilder.addLocals really needs to be based on the actual calling convention that was used when compiling the method.

I actually expected that the API introduced in #4505 already took care of this, but that doesn't seem to be the case. As far as I can tell, when creating a synthetic location record, ParamLocationProducer also uses the same calling convention for all methods.

So I think the location info API should be fixed to use the actual calling convention (see SubstrateCallingConvention), and this PR should be reworked to use the location info API. That should simplify the logic in CVSymbolSubsectionBuilder.addLocals quite a bit, but more importantly it should ensure that it is correct.

adinn · 2023-08-09T13:56:37Z

In particular, I don't think we should hardcode the same calling convention for all methods as is done in this PR because that is clearly incorrect.

Clearly? ... Err .. I mean ... Clearly, yes! of course!

Instead, I think the logic in CVSymbolSubsectionBuilder.addLocals really needs to be based on the actual calling convention that was used when compiling the method.

I was not aware that that different compiled methods had different calling conventions (for a given architecture, that is).

I actually expected that the API introduced in #4505 already took care of this, but that doesn't seem to be the case. As far as I can tell, when creating a synthetic location record, ParamLocationProducer also uses the same calling convention for all methods.

Yes, for Linux ParamLocationProducer currently only takes CPU (AMD64/AArch64) into account when generating synthetic locations for parameters and this was certainly not questioned when #4505 was reviewed. The current implementation assumes that all compiled methods retrieved from the native image code heap will pass arguments using a single calling convention specific to the CPU type. Is that incorrect on Linux? Or is it just an issue on Windows (or MacOS)?

If there is a need for different calling conventions according to the type of the compiled method then can you clarify 1) what OS/CPU combinations it applies for; also 2) what property of the method leads to it being compiled with a given calling convention?

Is this a requirement for native image code or is it, say, only for code generated by Truffle? or some other type of generated code?

So I think the location info API should be fixed to use the actual calling convention (see SubstrateCallingConvention), and this PR should be reworked to use the location info API. That should simplify the logic in CVSymbolSubsectionBuilder.addLocals quite a bit, but more importantly it should ensure that it is correct.

So, it seems you are suggesting that ParamLocationProducer needs to generalized to operate with reference to a SubstrateCallingConvention for all cases, even Linux, and that a PR to that effect is needed as a prerequisite change before the current PR can proceed. Is that correct? If so then I'll really need answers to the above questions.

stooke · 2023-08-09T14:13:20Z

Looking at the code in my repo (which needs a rebase so is slightly our of date), in SubstrateCallingConventionKind.java, there are only three calling conventions - Java (needed), Native (generated by the underlying C/C++ compilers and ForwardReturnValue, which is never used, only checked for. I think it's perfectly valid, if inelegant, for the debuginfo generator to simply check that the calling convention is Java and complain otherwise.

adinn · 2023-08-09T16:15:29Z

@pejovica Like Simon I'm also puzzled as to where you think there is a problem here. The Native calling convention is used in a very few places. One use that can be discounted immediately is when generating calls to a foreign function (which clearly has nothing to do with input parameters to compiled methods passed to the debug info generator).

The only place where I found the Native calling convention being used to describe parameters for a compiler-generated method was in class JNIJavaCallTrampolineHolder. The native methods declared by that class get custom translated to trampoline methods -- simple stubs which execute an indirect jump to a target method. However, the methods involved (such as varargsJavaCallTrampoline) are declared as static and with signature ()V so the generator has no parameters to place i.e. the calling convention is irrelevant.

Is there some other case I have missed where a called method has a non-empty call signature that needs to be interpreted using the Native calling convention?

@olpaw are you aware of a problem here?

pejovica · 2023-08-10T11:30:37Z

@adinn @stooke There seems to be some misunderstanding about how calling from native works, but literally anything that can be called from native must be compiled with the Native calling convention for the call to succeed. This includes all methods annotated with the @CEntryPoint annotation, but as you've already noticed we also have a bunch of generated wrappers for Java methods that can be called via JNI (that's what JNICallTrampolineMethods are for). So for example, if I were to set a breakpoint on the entry to main, the parameters argc and argv would be located according to the Native calling convention, meaning that PR as is would display the wrong thing. This sounds like a problem to me.

adinn · 2023-08-11T11:12:33Z

@pejovica I take your point and agree that ParamLocationProducer needs to be updated to respect use of the Native calling convention by the relevant subset of the generated method base. That is required to ensure both Windows and Linux record the correct local var locations for the those methods in the associated debug info. I will create an issue and raise a PR to fix that.

However, I don't understand why you appear to be treating that as a blocker for this patch. I don't think any of the code here will need to be changed after the above issue is fixed i.e. pushing it now does not imply rework later. I don't believe pushing the patch will risk any serious consequences, such as crashing the runtime or Windows debugger (otherwise I would expect to see the same outcome on Linux). It will mean that Windows debugger users may be misled about input arguments for a small number of methods (as currently happens on Linux). However, in the case of almost all methods the patch will provide valuable information to Windows debugger users (just as it does on Linux) and would be useful to have right now. Not only that but pushing it will also allow Simon to present the follow up patches which shodl significantly improve windows debugging. Is there a reason not to proceed with this PR that I am missing?

pejovica · 2023-08-14T11:18:38Z

@pejovica I take your point and agree that ParamLocationProducer needs to be updated to respect use of the Native calling convention by the relevant subset of the generated method base. That is required to ensure both Windows and Linux record the correct local var locations for the those methods in the associated debug info. I will create an issue and raise a PR to fix that.

@adinn Thanks, that would be great.

However, I don't understand why you appear to be treating that as a blocker for this patch. I don't think any of the code here will need to be changed after the above issue is fixed i.e. pushing it now does not imply rework later...

No, I don't think it is a blocker, but I also don't think we need another copy of code dealing with calling conventions. Note that CVSymbolSubsectionBuilder.addLocal effectively duplicates the ParamLocationProducer code, and since it doesn't use DebugLocalValueInfo at all, I don't see how we can avoid reworking this code later. That's why I suggested that this PR should be reworked to use the appropriate API.

stooke · 2023-08-14T12:09:21Z

@pejovica , as discussed before, this code lays the groundwork for the full implementation. The current variable information code in this PR is more a proof of concept that is still incredibly useful to Windows developers.

ParamLocationProducer is only partially useful for Windows as is - the register specifications in CodeView are sensitive to type. Simply saying a short lives in r9 will not work; the correct register is 'r9w' for example. Proper modification of ParamLocationProvider is something that could happen as part of the PR to handle native code calling conventions.

pejovica · 2023-08-21T13:06:22Z

@pejovica , as discussed before, this code lays the groundwork for the full implementation. The current variable information code in this PR is more a proof of concept that is still incredibly useful to Windows developers.

Yes, I understand that this is just laying the groundwork for a full implementation and I fully agree that it is very useful, so all I ask is that a sound foundation is laid. Note that before a proper API was introduced, this would have required direct use of our calling convention support, but even then there would be no need to duplicate any of that logic here.

ParamLocationProducer is only partially useful for Windows as is - the register specifications in CodeView are sensitive to type. Simply saying a short lives in r9 will not work; the correct register is 'r9w' for example. Proper modification of ParamLocationProvider is something that could happen as part of the PR to handle native code calling conventions.

This is actually another reason why I think this PR should be based on existing APIs: it will allow us to see if there are any issues that need to be addressed. Because if the existing APIs aren't sufficient to describe method parameters at their entry points, I don't see how they would be sufficient for anything more complicated. However, I don't expect this PR to address such issues, e.g., I'm fine if you leave dealing with the parameter sizes as a to-do task referencing the appropriate issue.

wirthi · 2025-07-18T15:53:47Z

@stooke thanks for your updates. The responsible engineer on our side is currently on leave, but I expect we can review and merge this mid August.

# Conflicts: # substratevm/src/com.oracle.objectfile/src/com/oracle/objectfile/pecoff/cv/CVLineRecordBuilder.java # substratevm/src/com.oracle.objectfile/src/com/oracle/objectfile/pecoff/cv/CVRegisterUtil.java # substratevm/src/com.oracle.objectfile/src/com/oracle/objectfile/pecoff/cv/CVSymbolSubsectionBuilder.java # substratevm/src/com.oracle.objectfile/src/com/oracle/objectfile/pecoff/cv/CVTypeSectionBuilder.java

stooke · 2025-08-07T17:42:02Z

@stooke thanks for your updates. The responsible engineer on our side is currently on leave, but I expect we can review and merge this mid August.

I look forward to it! I notice that there have been some changes in the mainline, should I update the PR - I'm hesitant to reset the clock...

stooke · 2025-08-14T11:44:07Z

@wirthi @pejovica there have been changed in the mainline - should I update this branch? I really don't want to reset the clock again on this.

wirthi · 2025-08-21T12:36:25Z

@stooke there is no downside in updating the branch, if anything it would make it easier for us to adopt it.

pejovica · 2025-09-04T00:48:19Z

@stooke Hey, I’ve finally picked this back up—thanks for your patience. I did some initial testing with the debugger against the current tip, and things look good. I’m digging back into the details and will follow up with a deeper pass soon.

substratevm/src/com.oracle.objectfile/src/com/oracle/objectfile/pecoff/cv/CVRegisterUtil.java

pejovica · 2025-09-23T10:28:50Z

substratevm/src/com.oracle.objectfile/src/com/oracle/objectfile/pecoff/cv/CVRegisterUtil.java

+
+    /* Convert a Java register number to a CodeView register code */
+    /* the CodeView code depends upon the register type and size */
+    static short getCVRegister(int javaReg, TypeEntry typeEntry) {


The contract of this method seems unclear. It should either (a) be defensive—use runtime checks and return -1 on any error; or (b) assume validated inputs—keep the asserts and drop runtime checks. The current mix is inconsistent; moreover, some conditions directly conflict (assert 0 <= javaReg <= MAX, then check javaReg > MAX; assert cvReg != null, then check cvReg == null).

Understood. I have clarified the intent via reordering, comments, and a warning message.
The intent is that production code would continue with a warning (and no symbol emitted) while debug code would trigger an assert so the code could be fixed and not ignored.

stooke · 2025-09-23T14:44:15Z

@pejovica thank you for your review! I have tried to address your points with the latest push.

...tevm/src/com.oracle.objectfile/src/com/oracle/objectfile/pecoff/cv/CVTypeSectionBuilder.java

substratevm/src/com.oracle.objectfile/src/com/oracle/objectfile/pecoff/cv/CVTypeRecord.java

pejovica · 2025-10-01T11:21:19Z

...tratevm/src/com.oracle.objectfile/src/com/oracle/objectfile/pecoff/cv/CVSymbolSubrecord.java

+        @Override
+        protected int computeContents(byte[] buffer, int initialPos) {
+            int pos = CVUtil.putInt(typeIndex, buffer, initialPos);
+            pos = CVUtil.putShort((short) flags, buffer, pos);


Seems cleaner to declare flags as short.

pejovica · 2025-10-01T11:47:18Z

...tratevm/src/com.oracle.objectfile/src/com/oracle/objectfile/pecoff/cv/CVSymbolSubrecord.java

+        private final short register;
+        private final short attr;
+
+        CVSymbolDefRangeRegisterRecord(CVDebugInfo debugInfo, String procName, int procOffset, int length, short register) {


I’d declare length as short here to match the base class.

pejovica · 2025-10-01T12:17:15Z

...tratevm/src/com.oracle.objectfile/src/com/oracle/objectfile/pecoff/cv/CVSymbolSubrecord.java

        }
    }

+    @SuppressWarnings("unused")


Seems not needed; class is used.

Suggested change

@SuppressWarnings("unused")

pejovica · 2025-10-01T13:32:29Z

...tratevm/src/com.oracle.objectfile/src/com/oracle/objectfile/pecoff/cv/CVSymbolSubrecord.java


-        CVSymbolGProc32Record(CVDebugInfo cvDebugInfo, String symbolName, String displayName, int pparent, int pend, int pnext, int proclen, int debugStart, int debugEnd, int typeIndex,
+        @SuppressWarnings("unused")
+        CVSymbolGProc32Record(CVDebugInfo cvDebugInfo, String symbolName, String displayName, int pparent, int pend, int pnext, long proclen, int debugStart, int debugEnd, int typeIndex,


Any reason to keep S_GPROC32 since it’s no longer used? If not, I’d suggest renaming CVSymbolGProc32Record to CVSymbolGProc32IdRecord and switching the record type to S_GPROC32_ID.

pejovica · 2025-10-03T09:11:22Z

...src/com.oracle.objectfile/src/com/oracle/objectfile/pecoff/cv/CVSymbolSubsectionBuilder.java


 final class CVSymbolSubsectionBuilder {

+    private static final int S_LOCAL_FLAGS_IS_PARAM = 1;


Might be better placed in CVSymbolLocalRecord.

pejovica · 2025-10-03T15:25:31Z

...src/com.oracle.objectfile/src/com/oracle/objectfile/pecoff/cv/CVSymbolSubsectionBuilder.java

-        /* TODO: add local variables, and their types. */
-        /* TODO: add block definitions. */
+        /* it's costly to compute this, so only compute it once */
+        Map<LocalEntry, List<Range>> varRangeMap = primaryRange.getVarRangeMap();


Looks like getVarRangeMap already caches its result, so is this local cache still needed?

pejovica · 2025-10-03T15:52:56Z

...src/com.oracle.objectfile/src/com/oracle/objectfile/pecoff/cv/CVSymbolSubsectionBuilder.java

+        final Range primaryRange = primaryEntry.primary();
+        /* The name as exposed to the linker. */
+        final String externalName = primaryRange.getSymbolName();
+        final MethodEntry method = primaryRange.isPrimary() ? primaryRange.getMethodEntry() : primaryRange.getCallees().getFirst().getMethodEntry();


This can be simplified now that primaryEntry.primary() returns PrimaryRange.

Suggested change

final MethodEntry method = primaryRange.isPrimary() ? primaryRange.getMethodEntry() : primaryRange.getCallees().getFirst().getMethodEntry();

final MethodEntry method = primaryRange.getMethodEntry();

pejovica · 2025-10-03T16:50:07Z

...src/com.oracle.objectfile/src/com/oracle/objectfile/pecoff/cv/CVSymbolSubsectionBuilder.java

+            final int typeIndex = method.isThisParam(paramInfo)
+                            ? cvDebugInfo.getCVTypeSection().getIndexForPointer(paramType)
+                            : cvDebugInfo.getCVTypeSection().addTypeRecords(paramType).getSequenceNumber();


I think we should use getIndexForPointer for all params because addTypeRecords would return a non-pointer type index for object params.

Suggested change

final int typeIndex = method.isThisParam(paramInfo)

? cvDebugInfo.getCVTypeSection().getIndexForPointer(paramType)

: cvDebugInfo.getCVTypeSection().addTypeRecords(paramType).getSequenceNumber();

final int typeIndex = cvDebugInfo.getCVTypeSection().getIndexForPointer(paramType);

pejovica · 2025-10-03T17:43:18Z

...src/com.oracle.objectfile/src/com/oracle/objectfile/pecoff/cv/CVSymbolSubsectionBuilder.java

+        for (Range subrange : ranges) {
+            LocalValueEntry value = subrange.lookupValue(info);
+            if (value != null) {
+                if (subrange.getLo() == currentHigh && registerOrSlot == infoTypeToInt(value)) {


Have you considered merging discontinuous ranges via gaps? cvdump suggests there are plenty of opportunities.

pejovica · 2025-10-03T18:19:59Z

...src/com.oracle.objectfile/src/com/oracle/objectfile/pecoff/cv/CVSymbolSubsectionBuilder.java

+                    /* if we can, merge records */
+                    currentHigh = subrange.getHi();
+                    if (currentRecord != null) {
+                        currentRecord.length = (short) (currentHigh - currentRecord.procOffset - range.getLo());


I don’t think we should assume the combined length fits in a short. Could we check before merging and skip otherwise?

stooke added 2 commits December 16, 2022 11:22

Add local variable records and function parameter definitions.

416bc74

Small cleanup to get rid of unused record types.

6faffc6

oracle-contributor-agreement bot added the OCA Verified All contributors have signed the Oracle Contributor Agreement. label Dec 16, 2022

CHanges for Github gate.

f2f013a

fniephaus requested review from olpaw and pejovica December 16, 2022 20:13

fniephaus assigned stooke Dec 16, 2022

adinn reviewed Jan 11, 2023

View reviewed changes

...src/com.oracle.objectfile/src/com/oracle/objectfile/pecoff/cv/CVSymbolSubsectionBuilder.java Outdated Show resolved Hide resolved

adinn approved these changes Jan 11, 2023

View reviewed changes

Changes per @adinn review

569ab0d

stooke force-pushed the pr-windows-varinfo branch from 6e6e24a to 569ab0d Compare January 13, 2023 22:16

pejovica reviewed Feb 27, 2023

View reviewed changes

stooke added 2 commits May 1, 2023 16:42

Merge branch 'master' into pr-windows-varinfo

dbb6d61

use real names for parameter variables

82b891e

jerboaa added the redhat-interest label May 16, 2023

Merge branch 'master' of https://github.com/oracle/graal into pr-wind…

1e92fe5

…ows-varinfo

Merge remote-tracking branch 'origin' into pr-windows-varinfo

f08f67a

Merge branch 'master' into pr-windows-varinfo

2826cf1

stooke added 2 commits August 25, 2023 10:56

Merge branch 'master' into pr-windows-varinfo

b9be5b9

Define functions using S_GPROC32_ID records.

0b010df

wirthi changed the title ~~Windows Debug Information for local variables - prerequisite record definitions~~ [GR-44474] Windows Debug Information for local variables - prerequisite record definitions Jul 18, 2025

stooke added 6 commits July 28, 2025 10:52

Merge branch 'master' into pr_update_codeview

b08c76a

Merge branch 'master' into pr_update_codeview

5502391

changes for runtime debug option

23e296e

Merge branch 'master' into pr_update_codeview

8636f8e

fix up varinfo pr

6ac77fb

stooke added 3 commits August 12, 2025 09:34

Merge branch 'master' into pr-windows-varinfo-work

37c1ea9

fixes for new Method API

29e725a

revert test files

33449e4

stooke added 4 commits August 21, 2025 09:56

Merge branch 'master' into pr-windows-varinfo

732c955

remove duplicate import

945f1cb

changes for graal gate

3d06cb3

changes for graal checkstyle

03b2e1d

pejovica reviewed Sep 23, 2025

View reviewed changes

changes from code review

69894e3

stooke added 3 commits September 23, 2025 11:14

fix for Graal style gate

19328a7

use different logger

04d6db7

use different logger

e4524ed

pejovica reviewed Sep 26, 2025

View reviewed changes

...tevm/src/com.oracle.objectfile/src/com/oracle/objectfile/pecoff/cv/CVTypeSectionBuilder.java Outdated Show resolved Hide resolved

pejovica reviewed Sep 26, 2025

View reviewed changes

substratevm/src/com.oracle.objectfile/src/com/oracle/objectfile/pecoff/cv/CVTypeRecord.java Outdated Show resolved Hide resolved

pejovica reviewed Sep 26, 2025

View reviewed changes

substratevm/src/com.oracle.objectfile/src/com/oracle/objectfile/pecoff/cv/CVTypeRecord.java Outdated Show resolved Hide resolved

use MFuncId instead of FuncId record

156645d

pejovica reviewed Oct 3, 2025

View reviewed changes


		final class CVSymbolSubsectionBuilder {

		private static final int S_LOCAL_FLAGS_IS_PARAM = 1;

	final MethodEntry method = primaryRange.isPrimary() ? primaryRange.getMethodEntry() : primaryRange.getCallees().getFirst().getMethodEntry();
	final MethodEntry method = primaryRange.getMethodEntry();

[GR-44474] Windows Debug Information for local variables - prerequisite record definitions #5638

Are you sure you want to change the base?

[GR-44474] Windows Debug Information for local variables - prerequisite record definitions #5638

Uh oh!

Conversation

stooke commented Dec 16, 2022

Uh oh!

Uh oh!

adinn left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

adinn commented Jul 31, 2023

Uh oh!

pejovica commented Aug 9, 2023

Uh oh!

adinn commented Aug 9, 2023

Uh oh!

stooke commented Aug 9, 2023

Uh oh!

adinn commented Aug 9, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

pejovica commented Aug 10, 2023

Uh oh!

adinn commented Aug 11, 2023

Uh oh!

pejovica commented Aug 14, 2023

Uh oh!

stooke commented Aug 14, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

pejovica commented Aug 21, 2023

Uh oh!

wirthi commented Jul 18, 2025

Uh oh!

stooke commented Aug 7, 2025

Uh oh!

stooke commented Aug 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

wirthi commented Aug 21, 2025

Uh oh!

pejovica commented Sep 4, 2025

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

stooke commented Sep 23, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

adinn left a comment •

edited

Loading

adinn commented Aug 9, 2023 •

edited

Loading

stooke commented Aug 14, 2023 •

edited

Loading

stooke commented Aug 14, 2025 •

edited

Loading