Below test case shows the issue: Name (BT0P, Package (0x04) {}) ... Method (GBST, 4, NotSerialized) { Store (0x123, Index (Arg3, 0x00)) ... } Method (SBST, 0, NotSerialized) { XOr ( Derefof (Index (BT0I, 0x00)),0x01,Local0) Return ( GBST (0x00, HB0S, Local0, BT0P)) } Method (_BIF, 0, NotSerialized) { .. Store(SBST(), Debug) Store ("_BIF: Index(BT0P, 0x00)", Debug) .. } Debug result: .... exoparg1-0807 [42] ex_opcode_1A_0T_1R : NULL package element obj c12d8bc8 psparse-1120: *** Error: Method execution failed [\_SB_.PCI0.ISA_.EC__.BAT0._BT
Sorry, method _BIF should be: Method (_BIF, 0, NotSerialized) { Store(SBST(), Debug) Store (derefof(Index (BT0P, 0x00)), Local0) }
Created attachment 1796 [details] a proposal The problem is that if create package element with statement: Store (0xXXX, Index(ArgX, 0xXXX)), we should increment reference counter to the package element to prevent it could be removed as an operand in walk_state.
Patch for solving root of null pointer problem is avaliable at bug 1799
I'm a little concerned about all the gyrations about reference counts related to the Store opcode. There have been quite a few problems in this area. I don't understand how these problems could occur if we just followed the ACPI spec: 1. If "Store(1, Object)", follow conversion rules then copy to Destination. 2. If "Store(1, Arg0)", copy to Destination or DerefOf(Destination) if Destination is a reference. 3. If "Store(1, Local0)", copy to Destination without any conversion. Perhaps we should throw out these attempts to do reference counting (shared objects) and always copy according to the above rules. The only reason to avoid copying is performance and I don't think copying would hurt real world ACPI performance.
The proposed patch works and _BST evaluation once again works although I modified it slightly to make it simpler. I'm attaching that revised version.
Created attachment 1812 [details] Revised simpler patch -- works
The reference counting mechanism solves several issues, not just related to Store().