Internal error in syntaxcheck test

Jeffrey Hugo jhugo at codeaurora.org
Wed Oct 5 19:05:51 UTC 2016


On 10/5/2016 1:02 PM, Colin Ian King wrote:
> On 05/10/16 20:00, Al Stone wrote:
>> On 10/05/2016 12:56 PM, Colin Ian King wrote:
>>> On 05/10/16 19:54, Jeffrey Hugo wrote:
>>>> I'm encountering an odd error in the syntaxcheck test, and I'm trying to
>>>> debug why.  Any pointers would be appreciated.
>>>>
>>>> An example instance of the error I get:
>>>>
>>>> FAILED [HIGH] AMLAsmASL_MSG_CONSTANT_EVALUATION: Test 1, Assembler error
>>>> in line
>>>> 6136
>>>> Line | AML source
>>>> --------------------------------------------------------------------------------
>>>>
>>>> 06133|                     If (LNotEqual (ToInteger (Local0), 0x00))
>>>> 06134|                     {
>>>> 06135|                         ShiftLeft (Local0, 0x04, Local0)
>>>> 06136|                         Store (Concatenate (Concatenate
>>>> (Concatenate ("USB[", "0"), "]: Fused Value for TUNE2: "), ToHexString
>>>> (Local0)
>>>>      |          ^
>>>>      | Error 6014: Could not evaluate constant expression    (AE_NO_MEMORY)
>>>> 06137|                             ), Debug)
>>>> 06138|                     }
>>>> 06139|                     Else
>>>> ================================================================================
>>>>
>>>>
>>>> ADVICE: (for Error #6014, ASL_MSG_CONSTANT_EVALUATION): Failed to
>>>> evaluate a
>>>> constant expression, the compiler could not resolve a subtree for some
>>>> unknown
>>>> reason.
>>>>
>>>> I may be wrong, but this reads like some kind of internal error in the
>>>> test, rather than an issue with the DSDT table.
>>>>
>>>> The only odd thing is that for some reason, the disassembly split the
>>>> source line into two - 06137, above, is really a continuation of 06136.
>>>>
>>>> Manually disassemblying my compiled source with iasl -d, I see the same
>>>> odd split, but recompiling the disasembled source with iasl does not
>>>> generate any errors.
>>>>
>>>> I first see these errors with tag V16.05.00.  I did a git bisect between
>>>> V16.03.00 and V16.05.00, which pointed me at:
>>>>
>>>> commit 9cbc043fcc51d7de6dd8bc1680414a6248ad6cc6
>>>> Author: Colin Ian King <colin.king at canonical.com>
>>>> Date:   Fri Mar 18 23:58:30 2016 +0000
>>>>
>>>>     ACPICA: Update to version 20160318 (LP: #1559312)
>>>>
>>>>     Changes in this release of ACPICA are detailed at the following
>>>>     link on the ACPICA developer mailing list:
>>>>
>>>>     https://lists.acpica.org/pipermail/devel/2016-March/000894.html
>>>>
>>>>     Signed-off-by: Colin Ian King <colin.king at canonical.com>
>>>>     Acked-by: Alex Hung <alex.hung at canonical.com>
>>>>     Acked-by: Ivan Hu <ivan.hu at canonical.com>
>>>>
>>>> Is there some weird interaction between how FWTS runs syntaxcheck and
>>>> current versions of ACPICA?
>>>>
>>> It may be an interaction issue; the interfaces between FWTS and ACPICA
>>> may be buggy. Do you have the table available so I can debug this?
>>>
>>> Colin
>>>
>>>
>>
>> Off hand, I'm more inclined to believe ACPICA is the issue; the most
>> recent versions have been fiddling around with expressions and their
>> syntax a great deal, so something might be off in the way the expression
>> is being evaluated.
>>
> Well, if I can get my hands on the table I can bisect down the code in
> ACPICA and validate that assertion :-)
>
> Colin
>

Thanks for the speedy response.

The DSDT table I'm encountering this with is quite large.  Let me try to 
generate a minimal sample that exhibits the same issue.

-- 
Jeffrey Hugo
Qualcomm Datacenter Technologies as an affiliate of Qualcomm 
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.



More information about the fwts-devel mailing list