Skip to contentSkip to conversation

proposed patch for some segfaults encountered

RFC In review Al Stone 2 participants 15 messages Jun 1, 2015 – Jun 3, 2015 ACPI component architecture (acpica)

lore
Share & tools
lore

Al Stone

author
#0 lore raw

RFC 1/1 proposed patch for some segfaults encountered

It's not clear to me that this is the correct way to handle a segfault that was reported to me via Fedora.

Using the ssdt9.dat file attached, a simple "iasl -d ssdt9.dat" will segfault around calls to AcpiDmPromoteTarget -- and it turns out that the Target pointer being passed into that function was sometimes null but not being checked in the calling function, AcpiDmCheckForSymbolicOpcode. So, this patch adds in some checks for null pointers and can now get through this particular problem.

However, I did not study AcpiDmCheckForSymbolicOpcode long enough to determine if the Target pointer in that function should or should not ever be null. So, this patch fixes this issue, but it may not be the proper long term solution.

Signature · 8 lines
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3(a)redhat.com
-----------------------------------
source/components/disassembler/dmcstyle.c +6 -3
diff -Naur acpica-unix2-20150515.orig/source/components/disassembler/dmcstyle.c acpica-unix2-20150515/source/components/disassembler/dmcstyle.c
@@ -407,7 +407,7 @@
         {
             AcpiDmPromoteTarget (Op, Target);
 
-            if (!Target->Common.OperatorSymbol)
+            if (Target && !Target->Common.OperatorSymbol)
             {
                 Target->Common.OperatorSymbol = " = ";
             }

@@ -425,7 +425,7 @@
         Target = Child1->Common.Next;
         AcpiDmPromoteTarget (Op, Target);
 
-        if (!Target->Common.OperatorSymbol)
+        if (Target && !Target->Common.OperatorSymbol)
         {
             Target->Common.OperatorSymbol = " = ";
         }

@@ -446,7 +446,10 @@
             /* Valid target, not a placeholder */
 
             AcpiDmPromoteTarget (Op, Target);
-            Target->Common.OperatorSymbol = " = ~";
+	    if (Target)
+	    {
+            	Target->Common.OperatorSymbol = " = ~";
+	    }
         }
         else
         {
#1 lore raw

I think we have taken at least one look at this one. We added checks for null pointers, but then the compiler failed our test suite. So, we feel that the problem is a bit more complex. However, it is on our list of things to do.

Quoted 30 lines

-----Original Message-----
From: Devel [mailto:devel-bounces(a)acpica.org] On Behalf Of Al Stone
Sent: Monday, June 01, 2015 1:59 PM
To: devel(a)acpica.org
Subject: [Devel] [RFC] proposed patch for some segfaults encountered

It's not clear to me that this is the correct way to handle a segfault that was reported to me via Fedora.

Using the ssdt9.dat file attached, a simple "iasl -d ssdt9.dat" will segfault around calls to AcpiDmPromoteTarget -- and it turns out that the Target pointer being passed into that function was sometimes null but not being checked in the calling function, AcpiDmCheckForSymbolicOpcode. So, this patch adds in some checks for null pointers and can now get through this particular problem.

However, I did not study AcpiDmCheckForSymbolicOpcode long enough to determine if the Target pointer in that function should or should not ever be null. So, this patch fixes this issue, but it may not be the proper long term solution.

--
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3(a)redhat.com
-----------------------------------

author
#2 lore raw

Interesting. I'll double check the results from ASLTS but I don't recall seeing any changes.

Quoted 33 lines · Robert

I think we have taken at least one look at this one. We added checks for null pointers, but then the compiler failed our test suite. So, we feel that the problem is a bit more complex. However, it is on our list of things to do.

Quoted 30 lines

-----Original Message-----
From: Devel [mailto:devel-bounces(a)acpica.org] On Behalf Of Al Stone
Sent: Monday, June 01, 2015 1:59 PM
To: devel(a)acpica.org
Subject: [Devel] [RFC] proposed patch for some segfaults encountered

It's not clear to me that this is the correct way to handle a segfault that was reported to me via Fedora.

Using the ssdt9.dat file attached, a simple "iasl -d ssdt9.dat" will segfault around calls to AcpiDmPromoteTarget -- and it turns out that the Target pointer being passed into that function was sometimes null but not being checked in the calling function, AcpiDmCheckForSymbolicOpcode. So, this patch adds in some checks for null pointers and can now get through this particular problem.

However, I did not study AcpiDmCheckForSymbolicOpcode long enough to determine if the Target pointer in that function should or should not ever be null. So, this patch fixes this issue, but it may not be the proper long term solution.

--
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3(a)redhat.com
-----------------------------------

Signature · 8 lines
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3(a)redhat.com
-----------------------------------
#3 lore raw
In reply to Al Stone

Please send the ssdt9.dat file, it wasn't attached. Bob

Quoted 30 lines

-----Original Message-----
From: Devel [mailto:devel-bounces(a)acpica.org] On Behalf Of Al Stone
Sent: Monday, June 01, 2015 1:59 PM
To: devel(a)acpica.org
Subject: [Devel] [RFC] proposed patch for some segfaults encountered

It's not clear to me that this is the correct way to handle a segfault that was reported to me via Fedora.

Using the ssdt9.dat file attached, a simple "iasl -d ssdt9.dat" will segfault around calls to AcpiDmPromoteTarget -- and it turns out that the Target pointer being passed into that function was sometimes null but not being checked in the calling function, AcpiDmCheckForSymbolicOpcode. So, this patch adds in some checks for null pointers and can now get through this particular problem.

However, I did not study AcpiDmCheckForSymbolicOpcode long enough to determine if the Target pointer in that function should or should not ever be null. So, this patch fixes this issue, but it may not be the proper long term solution.

--
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3(a)redhat.com
-----------------------------------

author
#4 lore raw
Quoted 3 lines · Robert

Please send the ssdt9.dat file, it wasn't attached. Bob

Ooops. Sorry about that.

Signature · 8 lines
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3(a)redhat.com
-----------------------------------
#5 lore raw

Ok, I've been able to reproduce the problem. I'll let you know how things progress. Bob

Quoted 22 lines

-----Original Message-----
From: Al Stone [mailto:ahs3(a)redhat.com]
Sent: Tuesday, June 02, 2015 9:48 AM
To: Moore, Robert; devel(a)acpica.org
Subject: Re: [Devel] [RFC] proposed patch for some segfaults encountered

Quoted 3 lines · Robert

Please send the ssdt9.dat file, it wasn't attached. Bob

Ooops. Sorry about that.

--
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3(a)redhat.com
-----------------------------------

#6 lore raw
In reply to Al Stone

I'll need to disassemble with the DSDT and all SSDTs.

Do you have an acpidump for the machine? Otherwise, the binary files will be ok.

There are a lot of externals to other tables, and this may be a part of the problem.

Quoted 33 lines

-----Original Message-----
From: Moore, Robert
Sent: Tuesday, June 02, 2015 11:55 AM
To: 'Al Stone'; devel(a)acpica.org
Subject: RE: [Devel] [RFC] proposed patch for some segfaults encountered

Ok, I've been able to reproduce the problem. I'll let you know how things progress.
Bob

Quoted 22 lines

-----Original Message-----
From: Al Stone [mailto:ahs3(a)redhat.com]
Sent: Tuesday, June 02, 2015 9:48 AM
To: Moore, Robert; devel(a)acpica.org
Subject: Re: [Devel] [RFC] proposed patch for some segfaults encountered

Quoted 3 lines · Robert

Please send the ssdt9.dat file, it wasn't attached. Bob

Ooops. Sorry about that.

--
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3(a)redhat.com
-----------------------------------

#7 lore raw

It looks to me that the disassembler has to start guessing at the number of arguments for the various external control methods, and it begins to get seriously confused.

Just FYI, here is a full description of the problem:

4.4.1 Disassembly of Control Method Invocations

Summary of the external control method problem:
When the -e option is used with disassembly, the various SSDTs are simply loaded into a global namespace for the disassembler to use in order to resolve control method references (invocations). The disassembler tracks any such references, and will emit an External() statement for these types of methods, with the proper number of arguments .
Without the SSDTs, the AML does not contain enough information to properly disassemble the control method invocation -- because the disassembler does not know how many arguments to parse. An example: Assume we have two control methods. ABCD has one argument, and EFGH has zero arguments. Further, we have two additional control methods that invoke ABCD and EFGH, named T1 and T2:

    Method (ABCD, 1)
    {
    }
    Method (EFGH, 0)
    {
    }
    Method (T1)
    {
        ABCD (Add (2, 7, Local0))
    }
    Method (T2)
    {
        EFGH ()
        Add (2, 7, Local0)
    }

Here is the AML code that is generated for T1 and T2:

     185:      Method (T1)

0000034C: 14 10 54 31 5F 5F 00 ... "..T1__."

     186:      {
     187:          ABCD (Add (2, 7, Local0))
00000353:  41 42 43 44 ............    "ABCD"
00000357:  72 0A 02 0A 07 60 ......    "r....`"
     188:      }

     190:      Method (T2)

0000035D: 14 10 54 32 5F 5F 00 ... "..T2__."

     191:      {
     192:          EFGH ()

00000364: 45 46 47 48 ............ "EFGH"

     193:          Add (2, 7, Local0)

00000368: 72 0A 02 0A 07 60 ...... "r....`"

     194:      }

Note that the AML code for T1 and T2 is essentially identical. When disassembling this code, the methods ABCD and EFGH must be known to the disassembler, otherwise it does not know how to handle the method invocations. In other words, if ABCD and EFGH are actually external control methods appearing in an SSDT, the disassembler does not know what to do unless the owning SSDT has been loaded via the -e option.

4.4.1.1 ACPI 6.0 Solution - External() AML Opcode
In ACPI 6.0, a new AML opcode was defined to help with this problem. The opcode is not intended for execution by AML interpreters; its only purpose is to assist the disassembler with the control method argument count problem.

Quoted 15 lines

-----Original Message-----
From: Devel [mailto:devel-bounces(a)acpica.org] On Behalf Of Moore, Robert
Sent: Tuesday, June 02, 2015 12:06 PM
To: Al Stone; devel(a)acpica.org
Subject: Re: [Devel] [RFC] proposed patch for some segfaults encountered

I'll need to disassemble with the DSDT and all SSDTs.

Do you have an acpidump for the machine? Otherwise, the binary files will be ok.

There are a lot of externals to other tables, and this may be a part of the problem.

author
#12 lore raw
In reply to Moore
Quoted 5 lines · Robert

I'll need to disassemble with the DSDT and all SSDTs.

Do you have an acpidump for the machine? Otherwise, the binary files will be ok.

There are a lot of externals to other tables, and this may be a part of the problem.

Aha. So noted from the follow-on message.

I'll see if I can get the full tables. All that was provided to me was the one SSDT, but I'll ask the bug reporter.

Quoted 33 lines
Quoted 33 lines

-----Original Message-----
From: Moore, Robert
Sent: Tuesday, June 02, 2015 11:55 AM
To: 'Al Stone'; devel(a)acpica.org
Subject: RE: [Devel] [RFC] proposed patch for some segfaults encountered

Ok, I've been able to reproduce the problem. I'll let you know how things progress.
Bob

Quoted 22 lines

-----Original Message-----
From: Al Stone [mailto:ahs3(a)redhat.com]
Sent: Tuesday, June 02, 2015 9:48 AM
To: Moore, Robert; devel(a)acpica.org
Subject: Re: [Devel] [RFC] proposed patch for some segfaults encountered

Quoted 3 lines · Robert

Please send the ssdt9.dat file, it wasn't attached. Bob

Ooops. Sorry about that.

--
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3(a)redhat.com
-----------------------------------

Signature · 8 lines
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3(a)redhat.com
-----------------------------------
#8 lore raw
In reply to Moore

Hi,

Quoted 59 lines

From: Devel [mailto:devel-bounces(a)acpica.org] On Behalf Of Moore, Robert
Sent: Wednesday, June 03, 2015 4:06 AM

It looks to me that the disassembler has to start guessing at the number of arguments for the various external control methods, and it begins to get seriously confused.

Just FYI, here is a full description of the problem:

4.4.1 Disassembly of Control Method Invocations

Summary of the external control method problem:
When the -e option is used with disassembly, the various SSDTs are simply loaded into a global namespace for the disassembler to use in order to resolve control method references (invocations).
The disassembler tracks any such references, and will emit an External() statement for these types of methods, with the proper number of arguments .
Without the SSDTs, the AML does not contain enough information to properly disassemble the control method invocation -- because the disassembler does not know how many arguments to parse.
An example: Assume we have two control methods. ABCD has one argument, and EFGH has zero arguments. Further, we have two additional control methods that invoke ABCD and EFGH, named T1 and T2:

    Method (ABCD, 1)
    {
    }
    Method (EFGH, 0)
    {
    }
    Method (T1)
    {
        ABCD (Add (2, 7, Local0))
    }
    Method (T2)
    {
        EFGH ()
        Add (2, 7, Local0)
    }

Here is the AML code that is generated for T1 and T2:

     185:      Method (T1)

0000034C: 14 10 54 31 5F 5F 00 ... "..T1__."

     186:      {
     187:          ABCD (Add (2, 7, Local0))
00000353:  41 42 43 44 ............    "ABCD"
00000357:  72 0A 02 0A 07 60 ......    "r....`"
     188:      }

     190:      Method (T2)

0000035D: 14 10 54 32 5F 5F 00 ... "..T2__."

     191:      {
     192:          EFGH ()

00000364: 45 46 47 48 ............ "EFGH"

Quoted 7 lines
     193:          Add (2, 7, Local0)

00000368: 72 0A 02 0A 07 60 ...... "r....`"

     194:      }

Note that the AML code for T1 and T2 is essentially identical. When disassembling this code, the methods ABCD and EFGH must be known to the disassembler, otherwise it does not know how to handle the method invocations.

This is the problem in ACPI specification since DSDT 1.0:
MethodInvocation := NameString TermArgList
TermObj := NameSpaceModifierObj | NamedObj | Type1Opcode | Type2Opcode TermList := Nothing | <TermObj TermList>
There is no number of arguments defined in the grammer.

Quoted 2 lines

In other words, if ABCD and EFGH are actually external control methods appearing in an SSDT, the disassembler does not know what to do unless the owning SSDT has been loaded via the -e option.

Normally I will use the following command to decompile:

# iasl -e dsdt.dat -e ssdt*.dat -d ssdt9.dat
Which loads all tables in the same order as the OSPM (may still face issue if there is "Load/LoadTable" invoked during the table loading).
If this still failed, this was either a BIOS bug or an DSDT 2.0 compatible problem.

Thanks and best regards
-Lv

Quoted 27 lines

4.4.1.1 ACPI 6.0 Solution - External() AML Opcode
In ACPI 6.0, a new AML opcode was defined to help with this problem. The opcode is not intended for execution by AML interpreters; its only purpose is to assist the disassembler with the control method argument count problem.

Quoted 6 lines

-----Original Message-----
From: Devel [mailto:devel-bounces(a)acpica.org] On Behalf Of Moore, Robert
Sent: Tuesday, June 02, 2015 12:06 PM
To: Al Stone; devel(a)acpica.org
Subject: Re: [Devel] [RFC] proposed patch for some segfaults encountered

Quoted 9 lines

I'll need to disassemble with the DSDT and all SSDTs.

Do you have an acpidump for the machine? Otherwise, the binary files will be ok.

There are a lot of externals to other tables, and this may be a part of the problem.

_______________________________________________
Devel mailing list
Devel(a)acpica.org
https://lists.acpica.org/mailman/listinfo/devel

#9 lore raw

And of course, the warning message should be taken to heart:

/*
* iASL Warning: There were 4 external control methods found during
* disassembly, but additional ACPI tables to resolve these externals
* were not specified. This resulting disassembler output file may not
* compile because the disassembler did not know how many arguments
* to assign to these methods. To specify the tables needed to resolve
* external control method references, the -e option can be used to
* specify the filenames. Note: SSDTs can be dynamically loaded at
* runtime and may or may not be available via the host OS.
* Example iASL invocations:
* iasl -e ssdt1.aml ssdt2.aml ssdt3.aml -d dsdt.aml
* iasl -e dsdt.aml ssdt2.aml -d ssdt1.aml
* iasl -e ssdt*.aml -d dsdt.aml
*
* In addition, the -fe option can be used to specify a file containing
* control method external declarations with the associated method
* argument counts. Each line of the file must be of the form:
* External (<method pathname>, MethodObj, <argument count>)
* Invocation:
* iasl -fe refs.txt -d dsdt.aml
*
* The following methods were unresolved and many not compile properly
* because the disassembler had to guess at the number of arguments
* required for each:
*/

Quoted 133 lines

-----Original Message-----
From: Zheng, Lv
Sent: Tuesday, June 02, 2015 5:38 PM
To: Moore, Robert; Al Stone; devel(a)acpica.org
Subject: RE: [Devel] [RFC] proposed patch for some segfaults encountered

Hi,

Quoted 6 lines

From: Devel [mailto:devel-bounces(a)acpica.org] On Behalf Of Moore, Robert
Sent: Wednesday, June 03, 2015 4:06 AM

It looks to me that the disassembler has to start guessing at the number of arguments for the various external control methods, and it

begins to get seriously confused.

Quoted 8 lines

Just FYI, here is a full description of the problem:

4.4.1 Disassembly of Control Method Invocations

Summary of the external control method problem:
When the -e option is used with disassembly, the various SSDTs are simply loaded into a global namespace for the disassembler to use in

order to resolve control method references (invocations).

Quoted 2 lines

The disassembler tracks any such references, and will emit an External() statement for these types of methods, with the proper number

of arguments .

Quoted 2 lines

Without the SSDTs, the AML does not contain enough information to properly disassemble the control method invocation -- because the

disassembler does not know how many arguments to parse.

Quoted 2 lines

An example: Assume we have two control methods. ABCD has one argument, and EFGH has zero arguments. Further, we have two additional control

methods that invoke ABCD and EFGH, named T1 and T2:

Quoted 40 lines
    Method (ABCD, 1)
    {
    }
    Method (EFGH, 0)
    {
    }
    Method (T1)
    {
        ABCD (Add (2, 7, Local0))
    }
    Method (T2)
    {
        EFGH ()
        Add (2, 7, Local0)
    }

Here is the AML code that is generated for T1 and T2:

     185:      Method (T1)

0000034C: 14 10 54 31 5F 5F 00 ... "..T1__."

     186:      {
     187:          ABCD (Add (2, 7, Local0))
00000353:  41 42 43 44 ............    "ABCD"
00000357:  72 0A 02 0A 07 60 ......    "r....`"
     188:      }

     190:      Method (T2)

0000035D: 14 10 54 32 5F 5F 00 ... "..T2__."

     191:      {
     192:          EFGH ()

00000364: 45 46 47 48 ............ "EFGH"

Quoted 7 lines
     193:          Add (2, 7, Local0)

00000368: 72 0A 02 0A 07 60 ...... "r....`"

     194:      }

Note that the AML code for T1 and T2 is essentially identical. When disassembling this code, the methods ABCD and EFGH must be known to the

disassembler, otherwise it does not know how to handle the method invocations.

This is the problem in ACPI specification since DSDT 1.0:
MethodInvocation := NameString TermArgList TermObj := NameSpaceModifierObj | NamedObj | Type1Opcode | Type2Opcode TermList := Nothing | <TermObj TermList> There is no number of arguments defined in the grammer.

Quoted 2 lines

In other words, if ABCD and EFGH are actually external control methods appearing in an SSDT, the disassembler does not know what to do unless

the owning SSDT has been loaded via the -e option.

Normally I will use the following command to decompile:

# iasl -e dsdt.dat -e ssdt*.dat -d ssdt9.dat Which loads all tables in the
same order as the OSPM (may still face issue if there is "Load/LoadTable"
invoked during the table loading).
If this still failed, this was either a BIOS bug or an DSDT 2.0 compatible
problem.

Thanks and best regards
-Lv

Quoted 4 lines

4.4.1.1 ACPI 6.0 Solution - External() AML Opcode
In ACPI 6.0, a new AML opcode was defined to help with this problem. The opcode is not intended for execution by AML interpreters; its only

purpose is to assist the disassembler with the control method argument count problem.

Quoted 25 lines
Quoted 12 lines

-----Original Message-----
From: Devel [mailto:devel-bounces(a)acpica.org] On Behalf Of Moore, Robert
Sent: Tuesday, June 02, 2015 12:06 PM
To: Al Stone; devel(a)acpica.org
Subject: Re: [Devel] [RFC] proposed patch for some segfaults encountered

Quoted 9 lines

I'll need to disassemble with the DSDT and all SSDTs.

Do you have an acpidump for the machine? Otherwise, the binary files will be ok.

There are a lot of externals to other tables, and this may be a part of the problem.

_______________________________________________
Devel mailing list
Devel(a)acpica.org
https://lists.acpica.org/mailman/listinfo/devel

author
#10 lore raw

Yup. All true and duly noted. Unfortunately, I could only pass on what I've been given from the bug report. And, the warning was not showing up because of the segfault. Now that it does, it should help some.

The Fedora BZ, if you're interested, is here:

https://bugzilla.redhat.com/show_bug.cgi?id=1219341

Quoted 162 lines · Robert

And of course, the warning message should be taken to heart:

/*
* iASL Warning: There were 4 external control methods found during
* disassembly, but additional ACPI tables to resolve these externals
* were not specified. This resulting disassembler output file may not
* compile because the disassembler did not know how many arguments
* to assign to these methods. To specify the tables needed to resolve
* external control method references, the -e option can be used to
* specify the filenames. Note: SSDTs can be dynamically loaded at
* runtime and may or may not be available via the host OS.
* Example iASL invocations:
* iasl -e ssdt1.aml ssdt2.aml ssdt3.aml -d dsdt.aml
* iasl -e dsdt.aml ssdt2.aml -d ssdt1.aml
* iasl -e ssdt*.aml -d dsdt.aml
*
* In addition, the -fe option can be used to specify a file containing
* control method external declarations with the associated method
* argument counts. Each line of the file must be of the form:
* External (<method pathname>, MethodObj, <argument count>)
* Invocation:
* iasl -fe refs.txt -d dsdt.aml
*
* The following methods were unresolved and many not compile properly
* because the disassembler had to guess at the number of arguments
* required for each:
*/

Quoted 133 lines

-----Original Message-----
From: Zheng, Lv
Sent: Tuesday, June 02, 2015 5:38 PM
To: Moore, Robert; Al Stone; devel(a)acpica.org
Subject: RE: [Devel] [RFC] proposed patch for some segfaults encountered

Hi,

Quoted 6 lines

From: Devel [mailto:devel-bounces(a)acpica.org] On Behalf Of Moore, Robert
Sent: Wednesday, June 03, 2015 4:06 AM

It looks to me that the disassembler has to start guessing at the number of arguments for the various external control methods, and it

begins to get seriously confused.

Quoted 8 lines

Just FYI, here is a full description of the problem:

4.4.1 Disassembly of Control Method Invocations

Summary of the external control method problem:
When the -e option is used with disassembly, the various SSDTs are simply loaded into a global namespace for the disassembler to use in

order to resolve control method references (invocations).

Quoted 2 lines

The disassembler tracks any such references, and will emit an External() statement for these types of methods, with the proper number

of arguments .

Quoted 2 lines

Without the SSDTs, the AML does not contain enough information to properly disassemble the control method invocation -- because the

disassembler does not know how many arguments to parse.

Quoted 2 lines

An example: Assume we have two control methods. ABCD has one argument, and EFGH has zero arguments. Further, we have two additional control

methods that invoke ABCD and EFGH, named T1 and T2:

Quoted 40 lines
    Method (ABCD, 1)
    {
    }
    Method (EFGH, 0)
    {
    }
    Method (T1)
    {
        ABCD (Add (2, 7, Local0))
    }
    Method (T2)
    {
        EFGH ()
        Add (2, 7, Local0)
    }

Here is the AML code that is generated for T1 and T2:

     185:      Method (T1)

0000034C: 14 10 54 31 5F 5F 00 ... "..T1__."

     186:      {
     187:          ABCD (Add (2, 7, Local0))
00000353:  41 42 43 44 ............    "ABCD"
00000357:  72 0A 02 0A 07 60 ......    "r....`"
     188:      }

     190:      Method (T2)

0000035D: 14 10 54 32 5F 5F 00 ... "..T2__."

     191:      {
     192:          EFGH ()

00000364: 45 46 47 48 ............ "EFGH"

Quoted 7 lines
     193:          Add (2, 7, Local0)

00000368: 72 0A 02 0A 07 60 ...... "r....`"

     194:      }

Note that the AML code for T1 and T2 is essentially identical. When disassembling this code, the methods ABCD and EFGH must be known to the

disassembler, otherwise it does not know how to handle the method invocations.

This is the problem in ACPI specification since DSDT 1.0:
MethodInvocation := NameString TermArgList TermObj := NameSpaceModifierObj | NamedObj | Type1Opcode | Type2Opcode TermList := Nothing | <TermObj TermList> There is no number of arguments defined in the grammer.

Quoted 2 lines

In other words, if ABCD and EFGH are actually external control methods appearing in an SSDT, the disassembler does not know what to do unless

the owning SSDT has been loaded via the -e option.

Normally I will use the following command to decompile:

# iasl -e dsdt.dat -e ssdt*.dat -d ssdt9.dat Which loads all tables in the
same order as the OSPM (may still face issue if there is "Load/LoadTable"
invoked during the table loading).
If this still failed, this was either a BIOS bug or an DSDT 2.0 compatible
problem.

Thanks and best regards
-Lv

Quoted 4 lines

4.4.1.1 ACPI 6.0 Solution - External() AML Opcode
In ACPI 6.0, a new AML opcode was defined to help with this problem. The opcode is not intended for execution by AML interpreters; its only

purpose is to assist the disassembler with the control method argument count problem.

Quoted 25 lines
Quoted 12 lines

-----Original Message-----
From: Devel [mailto:devel-bounces(a)acpica.org] On Behalf Of Moore, Robert
Sent: Tuesday, June 02, 2015 12:06 PM
To: Al Stone; devel(a)acpica.org
Subject: Re: [Devel] [RFC] proposed patch for some segfaults encountered

Quoted 9 lines

I'll need to disassemble with the DSDT and all SSDTs.

Do you have an acpidump for the machine? Otherwise, the binary files will be ok.

There are a lot of externals to other tables, and this may be a part of the problem.

_______________________________________________
Devel mailing list
Devel(a)acpica.org
https://lists.acpica.org/mailman/listinfo/devel

Signature · 8 lines
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3(a)redhat.com
-----------------------------------
#11 lore raw

As far as the segfault, this issue becomes very problematic as the disassembler parse tree can become ill-formed and the results are somewhat unpredictable. However, we will continue to do what we can short of checking every single node in the parse tree for validity, which of course is a lot of work, CPU time, or both. Obviously, we want to of course make the disassembler as bulletproof as we can.

Quoted 202 lines

-----Original Message-----
From: Al Stone [mailto:ahs3(a)redhat.com]
Sent: Wednesday, June 03, 2015 12:54 PM
To: Moore, Robert; Zheng, Lv; devel(a)acpica.org
Subject: Re: [Devel] [RFC] proposed patch for some segfaults encountered

Yup. All true and duly noted. Unfortunately, I could only pass on what I've been given from the bug report. And, the warning was not showing up because of the segfault. Now that it does, it should help some.

The Fedora BZ, if you're interested, is here:

   https://bugzilla.redhat.com/show_bug.cgi?id=1219341
Quoted 5 lines · Robert

And of course, the warning message should be taken to heart:

/*
* iASL Warning: There were 4 external control methods found during
* disassembly, but additional ACPI tables to resolve these

externals

Quoted 1 line

* were not specified. This resulting disassembler output file may

not

Quoted 2 lines

* compile because the disassembler did not know how many arguments
* to assign to these methods. To specify the tables needed to

resolve

Quoted 9 lines

* external control method references, the -e option can be used to
* specify the filenames. Note: SSDTs can be dynamically loaded at
* runtime and may or may not be available via the host OS.
* Example iASL invocations:
* iasl -e ssdt1.aml ssdt2.aml ssdt3.aml -d dsdt.aml
* iasl -e dsdt.aml ssdt2.aml -d ssdt1.aml
* iasl -e ssdt*.aml -d dsdt.aml
*
* In addition, the -fe option can be used to specify a file

containing

Quoted 7 lines

* control method external declarations with the associated method
* argument counts. Each line of the file must be of the form:
* External (<method pathname>, MethodObj, <argument count>)
* Invocation:
* iasl -fe refs.txt -d dsdt.aml
*
* The following methods were unresolved and many not compile

properly

Quoted 106 lines

* because the disassembler had to guess at the number of arguments
* required for each:
*/

Quoted 101 lines

-----Original Message-----
From: Zheng, Lv
Sent: Tuesday, June 02, 2015 5:38 PM
To: Moore, Robert; Al Stone; devel(a)acpica.org
Subject: RE: [Devel] [RFC] proposed patch for some segfaults encountered

Hi,

Quoted 6 lines

From: Devel [mailto:devel-bounces(a)acpica.org] On Behalf Of Moore, Robert
Sent: Wednesday, June 03, 2015 4:06 AM

It looks to me that the disassembler has to start guessing at the number of arguments for the various external control methods, and it

begins to get seriously confused.

Quoted 8 lines

Just FYI, here is a full description of the problem:

4.4.1 Disassembly of Control Method Invocations

Summary of the external control method problem:
When the -e option is used with disassembly, the various SSDTs are simply loaded into a global namespace for the disassembler to use in

order to resolve control method references (invocations).

Quoted 3 lines

The disassembler tracks any such references, and will emit an External() statement for these types of methods, with the proper number

of arguments .

Quoted 2 lines

Without the SSDTs, the AML does not contain enough information to properly disassemble the control method invocation -- because the

disassembler does not know how many arguments to parse.

Quoted 3 lines

An example: Assume we have two control methods. ABCD has one argument, and EFGH has zero arguments. Further, we have two additional control

methods that invoke ABCD and EFGH, named T1 and T2:

Quoted 40 lines
    Method (ABCD, 1)
    {
    }
    Method (EFGH, 0)
    {
    }
    Method (T1)
    {
        ABCD (Add (2, 7, Local0))
    }
    Method (T2)
    {
        EFGH ()
        Add (2, 7, Local0)
    }

Here is the AML code that is generated for T1 and T2:

     185:      Method (T1)

0000034C: 14 10 54 31 5F 5F 00 ... "..T1__."

     186:      {
     187:          ABCD (Add (2, 7, Local0))
00000353:  41 42 43 44 ............    "ABCD"
00000357:  72 0A 02 0A 07 60 ......    "r....`"
     188:      }

     190:      Method (T2)

0000035D: 14 10 54 32 5F 5F 00 ... "..T2__."

     191:      {
     192:          EFGH ()

00000364: 45 46 47 48 ............ "EFGH"

Quoted 8 lines
     193:          Add (2, 7, Local0)

00000368: 72 0A 02 0A 07 60 ...... "r....`"

     194:      }

Note that the AML code for T1 and T2 is essentially identical. When disassembling this code, the methods ABCD and EFGH must be known to the

disassembler, otherwise it does not know how to handle the method invocations.

This is the problem in ACPI specification since DSDT 1.0:
MethodInvocation := NameString TermArgList TermObj := NameSpaceModifierObj
| NamedObj | Type1Opcode | Type2Opcode TermList := Nothing | <TermObj TermList> There is no number of arguments defined in the grammer.

Quoted 3 lines

In other words, if ABCD and EFGH are actually external control methods appearing in an SSDT, the disassembler does not know what to do unless

the owning SSDT has been loaded via the -e option.

Normally I will use the following command to decompile:

# iasl -e dsdt.dat -e ssdt*.dat -d ssdt9.dat Which loads all tables
in the same order as the OSPM (may still face issue if there is

"Load/LoadTable"

Quoted 31 lines
Quoted 31 lines

invoked during the table loading).
If this still failed, this was either a BIOS bug or an DSDT 2.0 compatible problem.

Thanks and best regards
-Lv

Quoted 5 lines

4.4.1.1 ACPI 6.0 Solution - External() AML Opcode
In ACPI 6.0, a new AML opcode was defined to help with this problem. The opcode is not intended for execution by AML interpreters; its only

purpose is to assist the disassembler with the control method argument count problem.

Quoted 17 lines
Quoted 17 lines

-----Original Message-----
From: Devel [mailto:devel-bounces(a)acpica.org] On Behalf Of Moore, Robert
Sent: Tuesday, June 02, 2015 12:06 PM
To: Al Stone; devel(a)acpica.org
Subject: Re: [Devel] [RFC] proposed patch for some segfaults encountered

I'll need to disassemble with the DSDT and all SSDTs.

Do you have an acpidump for the machine? Otherwise, the binary files will be ok.

Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 4 lines

There are a lot of externals to other tables, and this may be a part of the problem.

_______________________________________________
Devel mailing list
Devel(a)acpica.org
https://lists.acpica.org/mailman/listinfo/devel

--
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3(a)redhat.com
-----------------------------------

#13 lore raw
In reply to Al Stone

Anyway, I added a check for a null target in AcpiDmIsValidTarget, and for the StoreOp target case. That should at least cover all of these types of cases.

Quoted 30 lines

-----Original Message-----
From: Devel [mailto:devel-bounces(a)acpica.org] On Behalf Of Al Stone
Sent: Monday, June 01, 2015 1:59 PM
To: devel(a)acpica.org
Subject: [Devel] [RFC] proposed patch for some segfaults encountered

It's not clear to me that this is the correct way to handle a segfault that was reported to me via Fedora.

Using the ssdt9.dat file attached, a simple "iasl -d ssdt9.dat" will segfault around calls to AcpiDmPromoteTarget -- and it turns out that the Target pointer being passed into that function was sometimes null but not being checked in the calling function, AcpiDmCheckForSymbolicOpcode. So, this patch adds in some checks for null pointers and can now get through this particular problem.

However, I did not study AcpiDmCheckForSymbolicOpcode long enough to determine if the Target pointer in that function should or should not ever be null. So, this patch fixes this issue, but it may not be the proper long term solution.

--
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3(a)redhat.com
-----------------------------------

author
#14 lore raw

Awesome. Thanks.

Quoted 33 lines · Robert

Anyway, I added a check for a null target in AcpiDmIsValidTarget, and for the StoreOp target case. That should at least cover all of these types of cases.

Quoted 30 lines

-----Original Message-----
From: Devel [mailto:devel-bounces(a)acpica.org] On Behalf Of Al Stone
Sent: Monday, June 01, 2015 1:59 PM
To: devel(a)acpica.org
Subject: [Devel] [RFC] proposed patch for some segfaults encountered

It's not clear to me that this is the correct way to handle a segfault that was reported to me via Fedora.

Using the ssdt9.dat file attached, a simple "iasl -d ssdt9.dat" will segfault around calls to AcpiDmPromoteTarget -- and it turns out that the Target pointer being passed into that function was sometimes null but not being checked in the calling function, AcpiDmCheckForSymbolicOpcode. So, this patch adds in some checks for null pointers and can now get through this particular problem.

However, I did not study AcpiDmCheckForSymbolicOpcode long enough to determine if the Target pointer in that function should or should not ever be null. So, this patch fixes this issue, but it may not be the proper long term solution.

--
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3(a)redhat.com
-----------------------------------

Signature · 8 lines
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3(a)redhat.com
-----------------------------------