The existing parser implementation has several issues and will, in many
cases incorrectly parse AML bytestreams that contain (among other
things):
- ambiguous method calls (same method name defined in multiple scopes)
- bank fields
- buffer fields where the length arg contains a method call
- named objects containing one or more '^' prefixes when defined inside
nested Scope elements (e.g. Scope(_SBRG){ Device(^PCIE){...} })
Unfortunately, these issues were discovered quite late while working on
the AML interpreter and while an attempt was made to correct some of
these (see previous commits), it turns out that the current codebase
cannot be refactored to fix all issues.
I have therefore decided to get rid of the current implementation and
replace it with a new one which will be created from scratch to address
all the above issues.
This commit just cleans up the codebase so the new parser can be added
via a future PR.
The previous implementation used brute-force approach where the parser
made an initial pass scanning the AML bytestream and looking for method
declaration opcodes. It then parsed out the method name and arg count
and populated a map which was used to detect the number of arguments to
be parsed upon encountering a method invocation. This approach proved to
be error-prone and would lead to an incorrect parse tree in the
following ASL example:
Method (FOOF, 1, NotSerialized)
{
Return ("bar")
}
Method (TST0, 0, NotSerialized)
{
FOOF(0)
\_SB.FOOF(2, 3)
}
Scope(\_SB){
// Another FOOF method in \_SB which takes a different arg count
Method (FOOF, 2, NotSerialized)
{
Return ("something")
}
}
In the above example the parser would correctly parse the first FOOF
call in TST0 but fail to parse the second invocation since the method
name contains a scope. The second invocation would actually yield the
following incorrect entity list (arguments appear as sibling entities):
Ref(\_SB.FOOF), Const(2), Const(3)
The new approach gets rid of the brute-force method and instead modifies
the initial parse of the tree not to parse the entities in the AML
method bodies but to instead track the start and end offset in the
AML stream for the body contents. In the second pass (where the parser
normally resolves symbol references), the parser can properly parse the
contents of method bodies since the entire AML tree is now known and the
parser can use the regular scope lookup rules to find the correct method
declaration for the invocation and figure out the argument count it
needs to parse.
This commit moves the AML entity definitions into the entity package and
makes them exportable so we can reference them from other packages.
In addition, the commit adds some missing entity structs that were
previously treated as generic entities (e.g. Processor, PowerResource
and ThermalZone).
Finally, this commit cleans the definitions and adds missing struct
attributes for the various field types (Field, IndexField, BankField)
This commit updates the post-parse step so that:
- the visitor not longer recurses into method bodies. Since code inside
methods may potentially generate dynamic/scoped entities or even use
conditional invocations (if CondRefOf(X) { X(...) }), symbol resolution
will be deferred to the AML interpreter.
- parent-child relationships between entities are checked and updated if
not properly specified
Since the ACPI standard allows forward function declarations this step
is required so we can properly parse the argument list for function
invocations. Contrary to other AML entities, method invocations do not
include any sort of pkgLength information so unless we track the
expected argument count for each function, our parser will not be able
to figure out where the argument list ends.
vmm.IdentityMapRegion can be used by device drivers that want to
establish an identity mapping for a contiguous physical memory block in
order to access some hardware or table.
