According to table 19-419 of the ACPI 6.3 specification, BufferFields
created using the ASL CreateField() Operator have been treated as
integers if the BufferField is small enough to fit inside of an ASL
integer (32-bits or 64-bits depending on the definition block
revision). If they are larger, buffer fields are treated as ASL
Buffer objects. However, this is not true for other AML interpreter
implementations.
It has been discovered that other AML interpreters always treat
buffer fields created by CreateField() as a buffer regardless of the
length of the buffer field.
More specifically, the Microsoft AML interpreter always treats buffer
fields created by the CreateField() operator as buffer. ACPICA
currently does this only when the field size is larger than the
maximum integer width. This causes problems with AML code shipped in
Microsoft Surface devices.
More details:
The control methods in these devices determine the success of an ASL
control method execution by examining the type resulting from storing
a buffer field created by a CreateField() operator. On success, a
Buffer object is expected, on failure an Integer containing an error
code. This buffer object is created with a dynamic size via the
CreateField() operator. Due to the difference in behavior, Buffer
values of small size are however converted to Integers and thus
interpreted by the control method as having failed, whereas in
reality it succeeded. Below is an example of a control method called
TEST that illustrates this behavior.
Method (CBUF) // Create a Buffer field
{
/*
* Depending on the value of RAND, ACPICA interpreter will treat
* BF00 as an integer or buffer.
*/
CreateField (BUFF, 0, RAND, BF00)
return (BF00)
}
Method (TEST)
{
/*
* Storing the value returned by CBUF to local0 will result in
* implicit type conversion outlined in the ACPI specification.
*
* ACPICA will treat local0 like an ASL integer if RAND is less
* than or equal to 64 or 32 (depending on the DefinitionBlock
* revision). If RAND is greater, it will be treated like an ASL
* buffer. Other implementations treat local0 like an ASL buffer
* regardless of the value of RAND.
*/
local0 = CBUF()
/*
* ObjectType of 0x03 represents an ASL Buffer
*/
if (ObjectType (Local0) != 0x03)
{
// Error on ACPICA if RAND is small enough
}
else
{
/*
* Success on APICA if RAND is large enough
* Other implementations always take this path because local0
* is always treated as a buffer.
*/
}
}
This change prohibits the previously mentioned integer conversion to
match other AML interpreter implementations (Microsoft) that do not
conform to the ACPI specification.
Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com>
Signed-off-by: Erik Schmauss <erik.schmauss@intel.com>
As of now, iASL does not keep track of parameter counts for external
declarations of methods. In order to determine the parameter count of
external control methods, iASL looks at the first method and saves
the parameter count in AML. However, this information is not present
during namespace cross reference.
This allows code like this to compile without errors:
DefinitionBlock ("", "DSDT", 2, "", "", 0x01)
{
External (DS01, MethodObj)
DS01(0x2,0x2) // DS01 is called with 2 parameters
DS01() // DS01 is called with 0 parameters
}
This change saves the parameter count of the first method call and
uses it to analyze subsequent method calls. This ensure that a method
that is declared external is called with the same amount of
parameters each time.
Signed-off-by: Erik Schmauss <erik.schmauss@intel.com>
They are unneeded because these functions do not return NULL. In the
case that these functions fail, they end up aborting the entire
program rather than returning NULL.
Reported-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Erik Schmauss <erik.schmauss@intel.com>
By setting the integer width, the disassembler no longer trucates 64-
bit integers in AML tables with revision 2 or higher.
Reported-by: Elia Geretto <elia.f.geretto@gmail.com>
Tested-by: Elia Geretto <elia.f.geretto@gmail.com>
Signed-off-by: Erik Schmauss <erik.schmauss@intel.com>
CreateBufferField is a deferred op that is typically processed in
load pass 2. However, disassembly of control method contents walk the
parse tree with ACPI_PARSE_LOAD_PASS1 and AML_CREATE operators are
processed in a later walk. This is a problem when there is a control
method that has the same name as the AML_CREATE object. In this case,
any use of the name segment will be detected as a method call rather
than a reference to a buffer field. If this is detected as a method
call, it can result in a mal-formed parse tree if the control methods
have parameters.
This change in processing AML_CREATE ops earlier solves this issue by
inserting the named object in the ACPI namespace so that references
to this name would be detected as a name string rather than a method
call.
Reported-by: Elia Geretto <elia.f.geretto@gmail.com>
Tested-by: Elia Geretto <elia.f.geretto@gmail.com>
Signed-off-by: Erik Schmauss <erik.schmauss@intel.com>
This change fixes the opcode walk and the transformation walk to only
traverse the parse tree after the entire parse tree has been formed.
parse tree. Walking the entire tree any earlier would require repeated
calls to walk the parse tree and results in longer execution time.
Signed-off-by: Erik Schmauss <erik.schmauss@intel.com>
In iASL, not being able to find the internal representation of an
input file is an unrecoverable condition. Instead of returning NULL
for this case, it's better to simply abort iASL instead of continuing
the compilation.
Reported-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Erik Schmauss <erik.schmauss@intel.com>
When all templates are being generated, iasl will exit with a non-zero
status even when everything works just fine. Correct the exit() call
to exit(0) for this case, instead of exit(1).
Signed-off-by: Al Stone <ahs3@ahs3.net>
The error return path is not free'ing previously allocated
resource LocalityBuffer and hence there is a memory leak. Fix this
by free'ing it before returning.
Fixes: c22c0b1df98c ("Data table compiler: Add error messages for SLIT locality buffers")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
