About 13 of the uACPI dumps fail to parse correctly because they rely on:
- SSDTs or DSDT using External to reference other SSDTs
- SSDTs not being loaded in the perfect order to guarantee Externals are defined in advance (instead, they're loaded in the order within the dump file)
I think I'm right in saying that there's no guarantee that SSDTs will be defined by the system in the perfect order? Also I don't know if Externals could form a loop where:
- SSDT1 defines Object A, uses External B in some method
- SSDT2 defines Object B, uses External A in some method
Below is an ASL script showing an example of this issue.
I guess the fix will be something along these lines?
- when parsing an
External:
- Create empty scopes if they haven't previously been encountered,
- Create placeholder objects - probably a new, internal-only,
Object/ObjectType,
- Return an error if a placeholder object is used as an argument in any operation.
Thoughts?
In this order, the tables can't be parsed - ParseFail(LevelDoesNotExist(AmlName([Root, Segment("_SB_"), Segment("SCP2")]))). Swap Table2 and Table3 and it can be parsed.
DefinitionBlock("", "SSDT", 1, "RSACPI", "Table2", 1) {
External (_SB.SCP2.SCP3)
Scope (_SB.SCP2.SCP3) {
Name (NAM3, 0x03)
}
}
DefinitionBlock("", "SSDT", 1, "RSACPI", "Table3", 1) {
Scope (_SB) {
Scope (SCP2) {
Scope (SCP3) {
Name (NAM2, 0x02)
}
}
}
}
DefinitionBlock("", "DSDT", 1, "RSACPI", "Table1", 1) {
Scope (_SB) {
Scope (SCP1) {
Name (NAM1, 0x01)
}
}
}
About 13 of the uACPI dumps fail to parse correctly because they rely on:
I think I'm right in saying that there's no guarantee that SSDTs will be defined by the system in the perfect order? Also I don't know if Externals could form a loop where:
Below is an ASL script showing an example of this issue.
I guess the fix will be something along these lines?
External:Object/ObjectType,Thoughts?