Added Tests and Coverage for Exception Handling(Illegal instruction, environment calls and misaligned address exceptions) and Trap State Restoration Exceptions #605

maria-rehman · 2025-01-22T11:31:27Z

Description

Includes tests and coverage of illegal instructions, environment calls, address misaligned exceptions, trap entry/exit state handling, and validation of mcause, scause, mtval, and stval values.

Related Issues

N/A

Ratified/Unratified Extensions

Ratified

List Extensions

RV32I: Base integer instruction set
S: Supervisor mode extension
U: User mode Extension
F: Single-precision floating-point extension
D: Double-Precision Floating-Point
Zicsr: Control and status register instructions

Reference Model Used

SAIL

Mandatory Checklist:

All tests are compliant with the test-format spec present in this repo
Ran the new tests on RISCOF with SAIL/Spike as reference model successfully
Ran the new tests on RISCOF in coverage mode
Link to Google-Drive folder containing the new coverage reports: > https://drive.google.com/drive/folders/1XwiTjZUGTCR7KKmygZ9NpDvy9ydp-lGH?usp=drive_link

Optional Checklist:

Tests are hand-written
Ran these tests on DUT model(Spike)
Modified test_macros.h file, added one macro to off mstatus.FS bits (RVTEST_FP_DISABLE)

…/s cause m/s tval csr after trap handling

…rv64i

allenjbaum

This has a misuse of ECALL in the test. IT should always set x2 to 0x1111_1111 to be handled by the trap handler properly. There also a misunderstanding of how unimplemented CSR are not handled in the spec (not guarnateed to trap), how misaligned occurs (may or may not trap), coments that don't seem to match the code.
The same procedue is used for all the test; it would make it more readable if you created a test macro for all the boilerplate to (greatly) reduce test size

allenjbaum · 2025-01-22T22:35:51Z

riscv-test-suite/rv32i_m/test/M_merged/M_excp_ecall_illegal_misaligned.S

+// get the address of the ecall instruction verify by checking both registers values
+
+	// machine ecall  
+	ecall


Unless the instruction immediately previous to ecall is a beq x,x,.+4, this must ensure that x2!=0 because the trap handler will treat that as a parameter to the handler.
(if X2==0, this is GOTO_MMODE, !=0, it's the ECALL test, anything is is a test failure)

allenjbaum · 2025-01-22T23:09:38Z

riscv-test-suite/rv32i_m/test/M_merged/M_excp_ecall_illegal_misaligned.S

+	LI (a4, CSR_MEDELEG)  
+	csrw medeleg, a4
+
+	ecall               // This exception will be handled in the machine mode 


Unless the instruction immediately previous to ecall is a beq x,x,.+4, this must ensure that x2!=0 because the trap handler will treat that as a parameter to the handler.
(if X2==0, this is GOTO_MMODE, !=0, it's the ECALL test, anything is is a test failure)

allenjbaum · 2025-01-22T23:13:15Z

riscv-test-suite/rv32i_m/test/M_merged/M_excp_ecall_illegal_misaligned.S

+    li t0, 0x3FC00000    //  Hex representation of 1.5 in IEEE-754 single-precision
+    li t1, 0x40200000    // Hex representation of 2.5 in IEEE-754 single-precision
+
+    // Move these values into floating-point registers


This test should also try a csrrd x2, FCSR (and FRM and FFLAGS to ensure that they trap also

allenjbaum · 2025-01-22T23:16:44Z

riscv-test-suite/rv32i_m/test/M_merged/M_excp_ecall_illegal_misaligned.S

+// mcause exception code will be  "4" in U mode
+*/
+
+	LI (a4, 0x0008) 


This is already tested in the misalign_lw_01.S test quite extensively. Also note that it very well might not trap, depending on misalign granularity

allenjbaum · 2025-01-23T15:31:48Z

riscv-test-suite/rv32i_m/test/M_merged/M_excp_ecall_illegal_misaligned.S

+
+// This test will check that in machine mode, a store address misaligned exception is raised when we try 
+// to attempt to store data to a misaligned memory address. For this we will check the log file 
+// that either it is giving the expected exception at that point and value of the mcause is "6" in M mode


Same comment: this appears to be redundant with (much more extensive) tests that already exist.

allenjbaum · 2025-01-24T13:35:34Z

riscv-test-suite/rv32i_m/test/S_merged/S_excp_ecall_illegal_misaligned.S

+    /* When we try to jump to the misaligned address then instead of instruction misaligned adddress it gives the illegal instruction exception */
+
+
+// This test will check that in Supervisor mode, a load address misaligned exception will be raised 


note that this may or may not trap, depending on the capabilities of the core

allenjbaum · 2025-01-24T13:36:57Z

riscv-test-suite/rv32i_m/test/S_merged/S_excp_ecall_illegal_misaligned.S

+
+	LA(x17,rvtest_data)
+	sw t1,0(x17)    // will not give any exception
+	sw t2,3(x17)    // will cause the exception


no guarantee that this will trap,. This should replace the first nop with li -1, and the 2nd nop with a SIGUPD.

allenjbaum · 2025-01-24T13:37:29Z

riscv-test-suite/rv32i_m/test/U_merged/U_excp_ecall_illegal_misaligned.S

+
+
+	// user ecall 
+	ecall


usuall ecall issue: needs x2!=0

allenjbaum · 2025-01-24T13:38:01Z

riscv-test-suite/rv32i_m/test/U_merged/U_excp_ecall_illegal_misaligned.S

+
+
+	LI (a4, 3)     
+	csrrc t1,0xFFF,a4  // accessing non existing CSR will generate the illegal instruction exception


no guarantee this will cause an exception. FFF is a custom readonly register, so there is no guarnatee what it will do if you try to execute this. Note that the you are in Umode at this time, so if you simply want to generate an illegal op exception, any legal mmode CSR will be safer and will guarantee the trap. But if the purpose is to show that a non-existent CSR access will trap - it's not possible unless Ssstrict extension is implemented (I think). At some point there may be a way to configure Sail to determine which CSRs will result in a trap if accessed, but even when that comes, you'll need to define it with an RVMODEL_CSR_TRAP variable (and skip the test if it isn't defined), so each implementation will have a slightly different test (but will have the same signature)

allenjbaum · 2025-01-24T13:42:57Z

riscv-test-suite/rv32i_m/test/U_merged/U_excp_ecall_illegal_misaligned.S

+	nop
+	nop
+
+	ecall               // This exception will be handled in the Supervisor mode 


make sure to set x2 correctly (!=0) Also: this is a case where you can never get back to Mmode, so you need to install a special illegal_op handler (which should uninstall itself) to get back

allenjbaum · 2025-05-13T05:40:24Z

riscv-test-suite/rv32i_m/test/S_merged/S_excp_ecall_illegal_misaligned.S

+	nop
+	nop
+
+	LI (a4, 0x0003) // this signature will give information that test for accessing another mode csr has successfully returned from the trap handler


If the trap handler wasn't ever entered, this would make it seem like it did.
The proper way to do this would be to preload a4 with some value X before the possible trap, load it immediately after the CSR write with a different value Y, and then store it. If the trap is entirely skipped, you'll see Y If it does trap and properly return you should see X.

allenjbaum · 2025-05-13T05:42:40Z

riscv-test-suite/rv32i_m/test/S_merged/S_excp_ecall_illegal_misaligned.S

+
+	// Try to write the supervisor mode  "read only CSR" then exception in the S mode will occur
+	LI (a4, 3)
+	csrrw t1, 0xDC0, a4      // this will give an illegal instruction as trying to write the read only register of supervisor mode


if CSR 0xDC0 has a name, it should be used. If it doesn't have a name, then it shouldn't be used in any test. Ditto for 0xFFF, unless that is known to always exist and always cause a trap.

allenjbaum · 2025-05-13T06:08:15Z

riscv-test-suite/rv32i_m/test/S_merged/S_excp_ecall_illegal_misaligned.S

+// after handling the trap to ensure it shows the expected values for different exceptions. 
+// Additionally, it confirms that stval contains the correct values for various exceptions.
+
+	LI (a4, CSR_MEDELEG)  


This is the wrong immediate; this will put the address of MEDELEG into the mdeleg CSR. You want to put the mask bit for the ECALL from Smode, which is 1<<CAUSE_SUPERVISOR_ECALL

Also: this is extremely dangerous. Once you've delegated ECALL to Smode, you can't goto Mmode or clear MEDELEG without installing a special illegal opcode handler and executing an illegal opcode.
The special handler will clear medeleg, then jump to the goto_mmode handler.
There is an array of pointers at excpt__MODE_()hndlr_tbl, and the offset CAUSE_SUPERVISOR_ECALL8 must be filled in with the address of this special handler, which will clear MEDELEG, restore the pointer to its default value of CAUSE_SUPERVISOR_ECALL2+1, and branch to rtn2mmode:. Note that if you're executing this in Umode, you need to do the same thing, except with value CAUSE_USER_ECALL
We probably should define a macro to set and clear this handler because I'm sure it will come up again...

allenjbaum · 2025-05-13T06:38:12Z

riscv-test-suite/rv32i_m/test/S_merged/S_excp_ecall_illegal_misaligned.S

+
+
+
+// This test checks that if an extension is turned off (e.g., FS bits [13 and 14] in mstatus 


The comment isn't quite correct. It isn't any extension, this is specifically FP extensions.
I believe that includes F, as well as D, Zfh, BF26, Zfa (though they all depend on F).
You may want to test it with ops other than just FADD, (especially CSR reads of FCSR, FRM, and FFLAGS)

allenjbaum · 2025-05-13T07:16:19Z

riscv-test-suite/rv32i_m/test/S_merged/S_excp_ecall_illegal_misaligned.S

+	nop
+	nop
+
+        LI (a4, 0x0009)   


This can be deleted since it is handled as above

allenjbaum · 2025-05-13T20:53:30Z

riscv-test-suite/rv32i_m/test/U_merged/U_excp_ecall_illegal_misaligned.S

+	nop 
+	nop
+
+	LI (a4, 0x0003) // this signature will give information that test for accessing another mode csr has successfully returned from the trap handler


I think this would be a more robust test (here, and in all other instances!) if the LI () was moved above the CSR access, and the 2 nops after was replaced with a different LI() value.

allenjbaum · 2025-05-13T23:33:41Z

riscv-test-suite/rv32i_m/test/U_merged/U_excp_ecall_illegal_misaligned.S

+
+	LI (a4, 2)																
+	csrw satp, a4           // writing satp exceptions will occur here
+	csrr t3,satp


these should be separated by at least one instruction, that instruction should reload or increment t4 by 1

allenjbaum · 2025-05-13T23:34:48Z

riscv-test-suite/rv32i_m/test/U_merged/U_excp_ecall_illegal_misaligned.S

+	csrw satp, a4           // writing satp exceptions will occur here
+	csrr t3,satp
+	nop
+	nop


these nops should be replace with an increment of t4 by 2

allenjbaum · 2025-05-13T23:36:29Z

riscv-test-suite/rv32i_m/test/U_merged/U_excp_ecall_illegal_misaligned.S

+	nop
+
+	sfence.vma              // using sfence.vma but no faults occur
+	nop


This noop should be replaced by an increment of t4 by 4, and the following LI() should be removed.
What this will do is produce a unique value in t4, where the lower 3 bits indicate which (if any) of the preceding ops failed to trap.

allenjbaum · 2025-05-13T23:40:52Z

riscv-test-suite/rv32i_m/test/U_merged/U_excp_ecall_illegal_misaligned.S

+// delegated the environment call in U mode to be handled in S mode
+
+
+	LI (a4, 0x100)  


please replace constant with a mnemonic, e.g. 1<<CAUSE_USER_ECALL

allenjbaum · 2025-05-13T23:46:37Z

riscv-test-suite/rv32i_m/test/U_merged/U_excp_ecall_illegal_misaligned.S

+    li t0, 0x3FC00000    //  Hex representation of 1.5 in IEEE-754 single-precision
+    li t1, 0x40200000    // Hex representation of 2.5 in IEEE-754 single-precision
+
+    // Move these values into floating-point registers


This should move the LI above each op that is supposed to trap, replace each noop pair with a increment by 1<<op# (this should be done everywhere you have a series of ops that trap . This ensures that if a trap is not taken in self_test mode, it will be caught .

allenjbaum · 2025-05-13T23:53:46Z

riscv-test-suite/rv32i_m/test/U_merged/U_excp_ecall_illegal_misaligned.S

+    /* When we try to jump to the misaligned address then instead of instruction misaligned adddress it gives the illegal instruction exception */
+
+
+// This test will check that in user mode, a load address misaligned exception will be raised 


Why do you expect an exception to be raised? It won't if there is HW support of misaligned accesses.
Note that regardless of wehther it does or not, you don't need to change the test, as it will compare with whatever Sail does. But: you have a vunch of ops that might or might not trap. You should remove the last LI(), remove the nops, and insert addi a4,a4,1<<op# after each op that might trap (even if you think it won't!), as mentioned above. This should be done in every test, so I won't mention i t again.

allenjbaum · 2025-05-13T23:57:03Z

riscv-test-suite/rv32i_m/test/traps/ms_cause_ms_tval_values/trap_entry_test_illegal.S

+
+	// illegal instruction exception in M mode
+	LI (t1, 0xdead)
+	csrw 0xFFF, t1      // accessing non existing CSR will generate the illegal instruction exception


NOT guaranteed to trap! Use a different method for causing an illegal op trap. Also: don't you have several tests that do this already? You don't need another.

allenjbaum · 2025-05-13T23:57:45Z

riscv-test-suite/rv32i_m/test/traps/ms_cause_ms_tval_values/trap_entry_test_illegal.S

+
+	// illegal instruction exception in S mode
+	LI (a4, 0xabcd)     
+	csrrc t1,0xFFF,a4  // accessing non existing CSR will generate the illegal instruction exception


as above: this doesn't work

allenjbaum · 2025-05-14T00:01:03Z

riscv-test-suite/rv32i_m/test/traps/ms_cause_ms_tval_values/trap_entry_test_illegal.S

+
+	// illegal instruction exception in U mode
+	LI (a4, 0xbeef)
+	csrrs t1,0xFFF,a4  // accessing non existing CSR will generate the illegal instruction exception


As above - not guaranteed to trap. Does this need to be a CSR access, or will execution of an allzero opcode work just as well?

allenjbaum · 2025-05-14T00:02:12Z

riscv-test-suite/rv32i_m/test/traps/ms_cause_ms_tval_values/trap_entry_test_illegal.S

+	nop
+	nop
+
+	LI (a4, 0x4)


USe a mnemonic, not a constant here, e.g. 1<<CAUSE_ILL_OP or whatever

allenjbaum · 2025-05-14T00:02:32Z

riscv-test-suite/rv32i_m/test/traps/ms_cause_ms_tval_values/trap_entry_test_illegal.S

+
+	// illegal instruction exception in M mode
+	LI (t1, 0xdead)
+	csrw 0xFFF, t1      // accessing non existing CSR will generate the illegal instruction exception


allenjbaum · 2025-05-14T00:07:46Z

riscv-test-suite/rv32i_m/test/traps/ms_cause_ms_tval_values/trap_entry_test_illegal.S

+
+	// illegal instruction exception in U mode
+	LI (a4, 0xbeef)
+	csrrs t1,0xFFF,a4  // accessing non existing CSR will generate the illegal instruction exception


pick a different illegal op

allenjbaum · 2025-05-14T00:13:23Z

riscv-test-suite/rv32i_m/test/traps/ms_cause_ms_tval_values/trap_entry_test_ld_sw.S

+
+    LI (a4, 0xcccc) 
+   	LA(x17,rvtest_data)
+	lw x5,1(x17)          // exception


SIGUPD after load tests should store the register that was loaded

allenjbaum · 2025-05-14T00:18:23Z

riscv-test-suite/rv32i_m/test/traps/ms_cause_ms_tval_values/trap_entry_test_ld_sw.S

@@ -0,0 +1,290 @@
+/* 
+/*
+        Note: Trap here in this file is taken load store address misaligned traps 


There is no guarantee that any of these will trap, so you have to ensure that the noop after every load/store loads a value different than the LI() before the load/store. If the op that traps is a load, then the way to do that is for SIGUPD to use the register that was loaded into. Also, make it clear that you're looking at different modes, and different widths being loaded or stored.

allenjbaum · 2025-05-14T00:19:53Z

riscv-test-suite/rv32i_m/test/traps/ms_cause_ms_tval_values/trap_entry_test_ld_sw.S

+
+    LI (a4, 0xaaaa) 
+   	LA(x17,rvtest_data)
+	lh x5,3(x17)


Use lh, x4... instead of x5, so SIGUPD gets the data that was loaded, to make sure it loaded the right thing (or didn't load anything, in the case a trap was taken.

allenjbaum · 2025-05-14T00:21:32Z

riscv-test-suite/rv32i_m/test/traps/ms_cause_ms_tval_values/trap_entry_test_ld_sw.S

+    nop
+
+	                       // Delegate and then check the same valuse for scause and stval//
+	LI (a4, 0x50)


replace constant with nmemonic

allenjbaum · 2025-05-14T00:24:45Z

riscv-test-suite/rv32i_m/test/undefined_opcodes/opcode_comb_not_covered.S

+	// Here below are the some opcode combinations that are not defined for any instruction 
+	// so when we use such opcodes they give the illegal instruction exception
+
+	// "110_0111" //


Undefined opcodes are not guaranteed to trap unless Zsstrict is implemented.
All zero ops are guaranteed, but not sure what else is.

allenjbaum · 2025-05-14T00:26:59Z

riscv-test-suite/rv64i_m/test/M_merged/M_excp_ecall_illegal_misaligned.S

+// instruction, mtval will contain the binary representation of illegal instruction
+
+	LI (t1, 0xdead)
+	csrw 0xFFF, t1      // accessing non existing CSR will generate the illegal instruction exception


no, this will not necessarily generate an illgal int exception !

allenjbaum · 2025-05-14T00:34:56Z

riscv-test-suite/rv64i_m/test/M_merged/M_excp_ecall_illegal_misaligned.S

+// are 00), trying to access it will cause an illegal instruction error. 
+
+
+ RVTEST_FP_DISABLE()  // this will set the FS bit in mstatsus to 00 means off


I'm not sure this work if the F extension isn't implemented (and you're not filtering the test based on that).
How would you test this if it isn't? You can't depend on any particular extension being implemented, or, if it is, that you can disable it (except FP)

allenjbaum · 2025-05-14T00:35:47Z

riscv-test-suite/rv64i_m/test/M_merged/M_excp_ecall_illegal_misaligned.S

+    /* When we try to jump to the misaligned address then instead of instruction misaligned adddress it gives the illegal instruction exception */
+
+ /*   
+// This test will check that in machine mode, a load address misaligned exception will be raised 


haven't you done this in several other tests already?

allenjbaum · 2025-05-14T00:39:16Z

riscv-test-suite/rv64i_m/test/U_merged/U_excp_ecall_illegal_misaligned.S

@@ -0,0 +1,262 @@
+/* // These tests are for the exceptions in U mode


I wonder if thse M/U/S mode tests should just loop 3 times, with different GO_TO_LOWER mode each pass through the loop (and a BASEUPD each time through). You'd got the number of tests by 3x.

allenjbaum · 2025-05-14T01:24:18Z

riscv-test-suite/env/test_macros.h

+
+#define RVTEST_FP_DISABLE()			;\
+ csrr a0, mstatus ;\
+ csrr a0, mtvec ;\


why is this instruction here?

allenjbaum

There are persistent problems in all the tests that need fixing.

It is not the case that misaligned accesses will trap.
They may or may not depending on whether HW misalignment is handled in HW,
and whether it crosses specific address boundaries.
This may not actually affect the tests too much - as long as whatever happens is
duplicated by the reference model. But we do have an entire set of much more
comprehensive misaligned tests (except they don't check [v]Umode or [v]Smode

I would instead ask that those tests be upgraded as I suggested, by looping
through in each mode, changing modes at each loop with BASEUPD in between

It is no longer the case that accesses to undefined CSRs will trap
Accesses to unimplemented CSRs are RSVD unless Zsstrict is implemented;
then they will trap; otherwise, they're unpredictable, so you can't use them in a test

It is no longer the case that FP ops will trap if mstatus.FS=0
This is only the case if F-extension is supported.
If it isn't then those ops are undefined, RSVD unless Zsstrict is implemented;
then they will trap; otherwise, they're unpredictable, so you can't use them in a test

It is not the case that undefined opcodes will trap (with few exceptions) .
Execution of undefined opcode are RSVD unless Zsstrict is implemented;
then they will trap; otherwise, they're unpredictable, so you can't use them in a test
you can't use them in a test. An allzeros opcode is guaranteed.

Tests use 2 noops after ops that trap, and none after ops that aren't supposed to
Only one noop is needed, but they should all be replaced with a addI of 1<<op#.
A series of ops will then set different bits depending on whether it didn't trap (or did)
and a single SIGUPD will enable SELF_TEST mode to catch cases where a trap didn't
happen the should have.
Note that this should be done even if you expect that the op will not trap

Tests delegate ECALL to Smode
When this happens, special measures are required in advance to get back to Mmode:
Installing a special illegal op handler that resets mdeleg & then uninstalls itself
Tests must execute an illegal op that goes to this handler before GOTO_MMODE

Constants are used instead of mnemonics
Specifically for values of mdeleg masks, but there are probably others

Many tests cases appear to be duplicated or redundant
e.g. there are many tests that write CSR 0xFFF to cause an illegal op trap.
There only needs to be one of them per test suite, not one per test case

There are a lot of tests that are identical except for the mode they are execute from
The number of tests can be cut down by just executing the loop 3 times,
with different GOTO_LOWER modes each time (so, keep loop count in a reg,
and branch to different ones depending on loop count,
with a BASE_UPD macro between each to make sure offset is updated correctly

SIGUPD after load should update the register that was (supposed to be) loaded
Explicit use of ECALL must guarantee that x2 is nonzero (and that the previous op is not a beq .+4), else it will alias to GOTO_MMODE or SELFCHK_MISCOMPARE

Almost all the comments I added in

maria-rehman added 22 commits January 13, 2025 19:27

Added tests for M mode exceptions

6f8344f

Added tests for U mode exceptions

930a1d3

Added tests for S mode exceptions

82e3be9

All merged M mode, S mode and U mode exceptions tests and tests for m…

c9d7241

…/s cause m/s tval csr after trap handling

Added test for different field values of fence.i

218753e

Added coverpoints

8866dbc

Modified the M mode coverpoints

d95831b

Modified the Smode Coverpoints

261cd84

Modified the tests for the U mode exceptions

e18c65d

Modified the coverpoints for the U mode exceptions

c28922e

Modified the test for fenci different field values

b8c7416

Added the test for undefined opcodes

12757a4

Seperate tests are removed

14bc1f0

Modified Coverpoint for M mode

6d605a2

Modified undefined opcodes test

0cb3e9d

Added the tests for the ecall, illegal and misaligned exceptions for …

b6f33c2

…rv64i

trap_entry_test_illegal.S

9561f96

Modified M mode exceptions

fdfa46c

Modified version

b819262

Modification in covergroups

e726788

Final Updated Version

9df4a90

Updated some comments in the file for future use

1dc4476

allenjbaum requested changes Jan 24, 2025

View reviewed changes

Merge branch 'dev' into exceptions

6199161

allenjbaum reviewed May 13, 2025

View reviewed changes

allenjbaum reviewed May 14, 2025

View reviewed changes

allenjbaum requested changes May 14, 2025

View reviewed changes

		/* When we try to jump to the misaligned address then instead of instruction misaligned adddress it gives the illegal instruction exception */


		// This test will check that in Supervisor mode, a load address misaligned exception will be raised



		LI (a4, 3)
		csrrc t1,0xFFF,a4 // accessing non existing CSR will generate the illegal instruction exception




		// This test checks that if an extension is turned off (e.g., FS bits [13 and 14] in mstatus

		// delegated the environment call in U mode to be handled in S mode


		LI (a4, 0x100)

		/* When we try to jump to the misaligned address then instead of instruction misaligned adddress it gives the illegal instruction exception */


		// This test will check that in user mode, a load address misaligned exception will be raised

		// are 00), trying to access it will cause an illegal instruction error.


		RVTEST_FP_DISABLE() // this will set the FS bit in mstatsus to 00 means off

		@@ -0,0 +1,262 @@
		/* // These tests are for the exceptions in U mode

Uh oh!

Added Tests and Coverage for Exception Handling(Illegal instruction, environment calls and misaligned address exceptions) and Trap State Restoration Exceptions #605

Are you sure you want to change the base?

Added Tests and Coverage for Exception Handling(Illegal instruction, environment calls and misaligned address exceptions) and Trap State Restoration Exceptions #605

Uh oh!

Conversation

maria-rehman commented Jan 22, 2025

Description

Related Issues

Ratified/Unratified Extensions

List Extensions

Reference Model Used

Mandatory Checklist:

Optional Checklist:

Uh oh!

allenjbaum left a comment

Choose a reason for hiding this comment

Uh oh!

allenjbaum Jan 22, 2025 • 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!

allenjbaum Jan 22, 2025 • 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!

Choose a reason for hiding this comment

Uh oh!

allenjbaum Jan 24, 2025 • 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!

allenjbaum Jan 24, 2025 • 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!

allenjbaum Jan 24, 2025 • 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!

allenjbaum Jan 24, 2025 • 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!

allenjbaum May 13, 2025 • 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!

allenjbaum May 13, 2025 • 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!

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!

allenjbaum May 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

allenjbaum Jan 22, 2025 •

edited

Loading

allenjbaum Jan 22, 2025 •

edited

Loading

allenjbaum Jan 24, 2025 •

edited

Loading

allenjbaum Jan 24, 2025 •

edited

Loading

allenjbaum Jan 24, 2025 •

edited

Loading

allenjbaum Jan 24, 2025 •

edited

Loading

allenjbaum May 13, 2025 •

edited

Loading

allenjbaum May 13, 2025 •

edited

Loading

allenjbaum May 13, 2025 •

edited

Loading

allenjbaum May 13, 2025 •

edited

Loading