iasl and SSDT disassembling limitations

iasl and SSDT disassembling limitations

[Henrique de Moraes Holschuh]

On Fri, 26 Sep 2008, Moore, Robert wrote:
> Most of the problems seen in the SSDT are related to the fact that the
> disassembler cannot always correctly disassemble code that contains calls
> to control methods that are external to the table. There is not enough
> information to disassemble correctly, and the table often needs to be
> repaired by hand.

Can iasl be improved to properly disassemble such tables if we give it ALL
tables to work with?

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

RE: iasl and SSDT disassembling limitations

[Moore, Robert]

Yes, it should be possible, and it is on our list of things to look at.

A little more info on the problem: Without the definition of the control method, the disassembler has no way of knowing how many arguments should be passed to the method. Without this information, it does not know how many expressions to parse after the control method invocation in order to create the arguments. The information is simply not available. So it tries to guess.

Bob


>-----Original Message-----
>From: Henrique de Moraes Holschuh [mailto:hmh@hmh.eng.br]
>Sent: Friday, September 26, 2008 9:09 AM
>To: Moore, Robert
>Cc: linux-acpi@vger.kernel.org
>Subject: iasl and SSDT disassembling limitations
>
>On Fri, 26 Sep 2008, Moore, Robert wrote:
>> Most of the problems seen in the SSDT are related to the fact that the
>> disassembler cannot always correctly disassemble code that contains calls
>> to control methods that are external to the table. There is not enough
>> information to disassemble correctly, and the table often needs to be
>> repaired by hand.
>
>Can iasl be improved to properly disassemble such tables if we give it ALL
>tables to work with?
>
>--
>  "One disk to rule them all, One disk to find them. One disk to bring
>  them all and in the darkness grind them. In the Land of Redmond
>  where the shadows lie." -- The Silicon Valley Tarot
>  Henrique Holschuh

Re: iasl and SSDT disassembling limitations

[Lin Ming]

We have added a "-e" option to iasl that include tables for external
symbol resolution. See
http://git.acpica.org/repos/?p=acpica.git;a=commitdiff;h=2f705a1b06109e12bd2659d0e12215710a5622b7


Example: To disassemble an SSDT with external symbols defined in DSDT:

iasl -e dsdt.aml -d ssdt.aml

Lin Ming


> From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-owner@vger.kernel.org] On Behalf Of Moore, Robert
> Sent: Saturday, September 27, 2008 12:49 AM
> To: Henrique de Moraes Holschuh
> Cc: linux-acpi@vger.kernel.org
> Subject: RE: iasl and SSDT disassembling limitations
> 
> Yes, it should be possible, and it is on our list of things to look at.
> 
> A little more info on the problem: Without the definition of the control method, the disassembler has no way of knowing how many arguments should be passed to the method. Without this information, it does not know how many expressions to parse after the control method invocation in order to create the arguments. The information is simply not available. So it tries to guess.
> 
> Bob
> 
> 
> >-----Original Message-----
> >From: Henrique de Moraes Holschuh [mailto:hmh@hmh.eng.br]
> >Sent: Friday, September 26, 2008 9:09 AM
> >To: Moore, Robert
> >Cc: linux-acpi@vger.kernel.org
> >Subject: iasl and SSDT disassembling limitations
> >
> >On Fri, 26 Sep 2008, Moore, Robert wrote:
> >> Most of the problems seen in the SSDT are related to the fact that the
> >> disassembler cannot always correctly disassemble code that contains calls
> >> to control methods that are external to the table. There is not enough
> >> information to disassemble correctly, and the table often needs to be
> >> repaired by hand.
> >
> >Can iasl be improved to properly disassemble such tables if we give it ALL
> >tables to work with?
> >
> >--
> >  "One disk to rule them all, One disk to find them. One disk to bring
> >  them all and in the darkness grind them. In the Land of Redmond
> >  where the shadows lie." -- The Silicon Valley Tarot
> >  Henrique Holschuh
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: iasl and SSDT disassembling limitations

[Frans Pop]

On Friday 24 October 2008, Lin Ming wrote:
> We have added a "-e" option to iasl that include tables for external
> symbol resolution.

Thanks very much. That does indeed give me a correctly disassembled table.

Would it be possible to add a warning when unavailable external symbols 
are detected? The warning could even be made verbose by saying that this 
may result in an incorrect dsl file and refer to the -e option (and maybe 
even specifically mention the dsdt table if that is the source for 
missing symbols in most cases).

Currently there is really no indication at all that something may have 
gone wrong or why until you look at the generated dsl file.

Cheers,
FJP

Re: iasl and SSDT disassembling limitations

[Lin Ming]

On Thu, 2008-10-30 at 17:11 +0800, Frans Pop wrote:
> On Friday 24 October 2008, Lin Ming wrote:
> > We have added a "-e" option to iasl that include tables for external
> > symbol resolution.
> 
> Thanks very much. That does indeed give me a correctly disassembled table.
> 
> Would it be possible to add a warning when unavailable external symbols 
> are detected? The warning could even be made verbose by saying that this 
> may result in an incorrect dsl file and refer to the -e option (and maybe 
> even specifically mention the dsdt table if that is the source for 
> missing symbols in most cases).

Good idea. Yes, we are going to add this warning message.

Lin Ming

> 
> Currently there is really no indication at all that something may have 
> gone wrong or why until you look at the generated dsl file.
> 
> Cheers,
> FJP

Re: iasl and SSDT disassembling limitations

[Thomas Renninger]

On Friday 24 October 2008 05:50:30 am Lin Ming wrote:
> We have added a "-e" option to iasl that include tables for external
> symbol resolution. See
> http://git.acpica.org/repos/?p=acpica.git;a=commitdiff;h=2f705a1b06109e12bd
>2659d0e12215710a5622b7
>
>
> Example: To disassemble an SSDT with external symbols defined in DSDT:
>
> iasl -e dsdt.aml -d ssdt.aml

I thought this option already existed for quite a while?
Did it get re-implemented?

IIRC I already saw references in both directions. SSDT is making use of 
variables declared in the DSDT and vice versa (rare, but it can happen).

IMO a proper long-term solution would be to be able to do:
iasl -d [DS]SDT*.dsl
iasl then parses every table, remembers unresolved objects and then goes 
through these, once the last table got parsed.

Probably one step harder to implement, do you think this is possible to do or 
should such things be considered as BIOS implementation bugs?

Thanks,

      Thomas

>
> Lin Ming
>
> > From: linux-acpi-owner@vger.kernel.org
> > [mailto:linux-acpi-owner@vger.kernel.org] On Behalf Of Moore, Robert
> > Sent: Saturday, September 27, 2008 12:49 AM
> > To: Henrique de Moraes Holschuh
> > Cc: linux-acpi@vger.kernel.org
> > Subject: RE: iasl and SSDT disassembling limitations
> >
> > Yes, it should be possible, and it is on our list of things to look at.
> >
> > A little more info on the problem: Without the definition of the control
> > method, the disassembler has no way of knowing how many arguments should
> > be passed to the method. Without this information, it does not know how
> > many expressions to parse after the control method invocation in order to
> > create the arguments. The information is simply not available. So it
> > tries to guess.
> >
> > Bob
> >
> > >-----Original Message-----
> > >From: Henrique de Moraes Holschuh [mailto:hmh@hmh.eng.br]
> > >Sent: Friday, September 26, 2008 9:09 AM
> > >To: Moore, Robert
> > >Cc: linux-acpi@vger.kernel.org
> > >Subject: iasl and SSDT disassembling limitations
> > >
> > >On Fri, 26 Sep 2008, Moore, Robert wrote:
> > >> Most of the problems seen in the SSDT are related to the fact that the
> > >> disassembler cannot always correctly disassemble code that contains
> > >> calls to control methods that are external to the table. There is not
> > >> enough information to disassemble correctly, and the table often needs
> > >> to be repaired by hand.
> > >
> > >Can iasl be improved to properly disassemble such tables if we give it
> > > ALL tables to work with?
> > >
> > >--
> > >  "One disk to rule them all, One disk to find them. One disk to bring
> > >  them all and in the darkness grind them. In the Land of Redmond
> > >  where the shadows lie." -- The Silicon Valley Tarot
> > >  Henrique Holschuh
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: iasl and SSDT disassembling limitations

[Lin Ming]

On Thu, 2008-11-13 at 08:17 +0800, Thomas Renninger wrote:
> On Friday 24 October 2008 05:50:30 am Lin Ming wrote:
> > We have added a "-e" option to iasl that include tables for external
> > symbol resolution. See
> > http://git.acpica.org/repos/?p=acpica.git;a=commitdiff;h=2f705a1b06109e12bd
> >2659d0e12215710a5622b7
> >
> >
> > Example: To disassemble an SSDT with external symbols defined in DSDT:
> >
> > iasl -e dsdt.aml -d ssdt.aml
> 
> I thought this option already existed for quite a while?
> Did it get re-implemented?

No, the original one is a NULL implementation.

> 
> IIRC I already saw references in both directions. SSDT is making use of 
> variables declared in the DSDT and vice versa (rare, but it can happen).
> 
> IMO a proper long-term solution would be to be able to do:
> iasl -d [DS]SDT*.dsl
> iasl then parses every table, remembers unresolved objects and then goes 
> through these, once the last table got parsed.
> 
> Probably one step harder to implement, do you think this is possible to do or 
> should such things be considered as BIOS implementation bugs?

It's possible, but harder. External symbol is not a BIOS bug.

iasl tries to guess the arguments of external methods, and it success at
most time (-e option is not needed).

But sometimes it fails, and then you can use -e option to include the
external tables to resolve the external symbols.

Lin Ming

> 
> Thanks,
> 
>       Thomas
> 
> >
> > Lin Ming
> >
> > > From: linux-acpi-owner@vger.kernel.org
> > > [mailto:linux-acpi-owner@vger.kernel.org] On Behalf Of Moore, Robert
> > > Sent: Saturday, September 27, 2008 12:49 AM
> > > To: Henrique de Moraes Holschuh
> > > Cc: linux-acpi@vger.kernel.org
> > > Subject: RE: iasl and SSDT disassembling limitations
> > >
> > > Yes, it should be possible, and it is on our list of things to look at.
> > >
> > > A little more info on the problem: Without the definition of the control
> > > method, the disassembler has no way of knowing how many arguments should
> > > be passed to the method. Without this information, it does not know how
> > > many expressions to parse after the control method invocation in order to
> > > create the arguments. The information is simply not available. So it
> > > tries to guess.
> > >
> > > Bob
> > >
> > > >-----Original Message-----
> > > >From: Henrique de Moraes Holschuh [mailto:hmh@hmh.eng.br]
> > > >Sent: Friday, September 26, 2008 9:09 AM
> > > >To: Moore, Robert
> > > >Cc: linux-acpi@vger.kernel.org
> > > >Subject: iasl and SSDT disassembling limitations
> > > >
> > > >On Fri, 26 Sep 2008, Moore, Robert wrote:
> > > >> Most of the problems seen in the SSDT are related to the fact that the
> > > >> disassembler cannot always correctly disassemble code that contains
> > > >> calls to control methods that are external to the table. There is not
> > > >> enough information to disassemble correctly, and the table often needs
> > > >> to be repaired by hand.
> > > >
> > > >Can iasl be improved to properly disassemble such tables if we give it
> > > > ALL tables to work with?
> > > >
> > > >--
> > > >  "One disk to rule them all, One disk to find them. One disk to bring
> > > >  them all and in the darkness grind them. In the Land of Redmond
> > > >  where the shadows lie." -- The Silicon Valley Tarot
> > > >  Henrique Holschuh
> > >
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> > > the body of a message to majordomo@vger.kernel.org
> > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 

Re: iasl and SSDT disassembling limitations

[Thomas Renninger]

On Thursday 13 November 2008 08:02:29 Lin Ming wrote:
> On Thu, 2008-11-13 at 08:17 +0800, Thomas Renninger wrote:
> > On Friday 24 October 2008 05:50:30 am Lin Ming wrote:
> > > We have added a "-e" option to iasl that include tables for external
> > > symbol resolution. See
> > > http://git.acpica.org/repos/?p=acpica.git;a=commitdiff;h=2f705a1b06109e
> > >12bd 2659d0e12215710a5622b7
> > >
> > >
> > > Example: To disassemble an SSDT with external symbols defined in DSDT:
> > >
> > > iasl -e dsdt.aml -d ssdt.aml
> >
> > I thought this option already existed for quite a while?
> > Did it get re-implemented?
>
> No, the original one is a NULL implementation.
It did not work, but it already remembered unresolved objects/functions and 
tried to resolve them correctly from the -e passed table.
Either this or I did mess up something completely when I played with that 
maybe a year ago.

>
> > IIRC I already saw references in both directions. SSDT is making use of
> > variables declared in the DSDT and vice versa (rare, but it can happen).
> >
> > IMO a proper long-term solution would be to be able to do:
> > iasl -d [DS]SDT*.dsl
> > iasl then parses every table, remembers unresolved objects and then goes
> > through these, once the last table got parsed.
> >
> > Probably one step harder to implement, do you think this is possible to
> > do or should such things be considered as BIOS implementation bugs?
>
> It's possible, but harder. External symbol is not a BIOS bug.
Do you plan to extend the functionality that external symbols can be
resolved in both directions, e.g. by passing all DSDT and SSDT tables:
iasl -d DSDT.dsl SSDT1.dsl SSDT2.dsl
I tried that unsuccessfully quite some time ago.
Now one still has an overview how this could be done :)
iasl -e DSDT.dsl SSDTx.dsl
should now work in much more cases, but I fear there will be some which
are still not covered (if DSDT references variables declared in SSDTs).

> iasl tries to guess the arguments of external methods, and it success at
> most time (-e option is not needed).
>
> But sometimes it fails, and then you can use -e option to include the
> external tables to resolve the external symbols.
Yes, and having this working makes it possible to more reliably check
BIOSes against ASL syntax errors.

Thanks a lot for your efforts,

     Thomas

> Lin Ming
>
> > Thanks,
> >
> >       Thomas
> >
> > > Lin Ming
> > >
> > > > From: linux-acpi-owner@vger.kernel.org
> > > > [mailto:linux-acpi-owner@vger.kernel.org] On Behalf Of Moore, Robert
> > > > Sent: Saturday, September 27, 2008 12:49 AM
> > > > To: Henrique de Moraes Holschuh
> > > > Cc: linux-acpi@vger.kernel.org
> > > > Subject: RE: iasl and SSDT disassembling limitations
> > > >
> > > > Yes, it should be possible, and it is on our list of things to look
> > > > at.
> > > >
> > > > A little more info on the problem: Without the definition of the
> > > > control method, the disassembler has no way of knowing how many
> > > > arguments should be passed to the method. Without this information,
> > > > it does not know how many expressions to parse after the control
> > > > method invocation in order to create the arguments. The information
> > > > is simply not available. So it tries to guess.
> > > >
> > > > Bob
> > > >
> > > > >-----Original Message-----
> > > > >From: Henrique de Moraes Holschuh [mailto:hmh@hmh.eng.br]
> > > > >Sent: Friday, September 26, 2008 9:09 AM
> > > > >To: Moore, Robert
> > > > >Cc: linux-acpi@vger.kernel.org
> > > > >Subject: iasl and SSDT disassembling limitations
> > > > >
> > > > >On Fri, 26 Sep 2008, Moore, Robert wrote:
> > > > >> Most of the problems seen in the SSDT are related to the fact that
> > > > >> the disassembler cannot always correctly disassemble code that
> > > > >> contains calls to control methods that are external to the table.
> > > > >> There is not enough information to disassemble correctly, and the
> > > > >> table often needs to be repaired by hand.
> > > > >
> > > > >Can iasl be improved to properly disassemble such tables if we give
> > > > > it ALL tables to work with?
> > > > >
> > > > >--
> > > > >  "One disk to rule them all, One disk to find them. One disk to
> > > > > bring them all and in the darkness grind them. In the Land of
> > > > > Redmond where the shadows lie." -- The Silicon Valley Tarot
> > > > >  Henrique Holschuh
> > > >
> > > > --
> > > > To unsubscribe from this list: send the line "unsubscribe linux-acpi"
> > > > in the body of a message to majordomo@vger.kernel.org
> > > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > >
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe linux-acpi"
> > > in the body of a message to majordomo@vger.kernel.org
> > > More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: iasl and SSDT disassembling limitations

[Lin Ming]

On Sat, 2008-11-15 at 00:28 +0800, Thomas Renninger wrote:
> On Thursday 13 November 2008 08:02:29 Lin Ming wrote:
> > On Thu, 2008-11-13 at 08:17 +0800, Thomas Renninger wrote:
> > > On Friday 24 October 2008 05:50:30 am Lin Ming wrote:
> > > > We have added a "-e" option to iasl that include tables for external
> > > > symbol resolution. See
> > > > http://git.acpica.org/repos/?p=acpica.git;a=commitdiff;h=2f705a1b06109e
> > > >12bd 2659d0e12215710a5622b7
> > > >
> > > >
> > > > Example: To disassemble an SSDT with external symbols defined in DSDT:
> > > >
> > > > iasl -e dsdt.aml -d ssdt.aml
> > >
> > > I thought this option already existed for quite a while?
> > > Did it get re-implemented?
> >
> > No, the original one is a NULL implementation.
> It did not work, but it already remembered unresolved objects/functions and 
> tried to resolve them correctly from the -e passed table.
> Either this or I did mess up something completely when I played with that 
> maybe a year ago.
> 
> >
> > > IIRC I already saw references in both directions. SSDT is making use of
> > > variables declared in the DSDT and vice versa (rare, but it can happen).
> > >
> > > IMO a proper long-term solution would be to be able to do:
> > > iasl -d [DS]SDT*.dsl
> > > iasl then parses every table, remembers unresolved objects and then goes
> > > through these, once the last table got parsed.
> > >
> > > Probably one step harder to implement, do you think this is possible to
> > > do or should such things be considered as BIOS implementation bugs?
> >
> > It's possible, but harder. External symbol is not a BIOS bug.
> Do you plan to extend the functionality that external symbols can be
> resolved in both directions, e.g. by passing all DSDT and SSDT tables:
> iasl -d DSDT.dsl SSDT1.dsl SSDT2.dsl

Yes, both directions.

> I tried that unsuccessfully quite some time ago.

I have some patches here.
You can try it again when next version of iasl is released.

Lin Ming

> Now one still has an overview how this could be done :)
> iasl -e DSDT.dsl SSDTx.dsl
> should now work in much more cases, but I fear there will be some which
> are still not covered (if DSDT references variables declared in SSDTs).
> 
> > iasl tries to guess the arguments of external methods, and it success at
> > most time (-e option is not needed).
> >
> > But sometimes it fails, and then you can use -e option to include the
> > external tables to resolve the external symbols.
> Yes, and having this working makes it possible to more reliably check
> BIOSes against ASL syntax errors.
> 
> Thanks a lot for your efforts,
> 
>      Thomas
> 
> > Lin Ming
> >
> > > Thanks,
> > >
> > >       Thomas
> > >
> > > > Lin Ming
> > > >
> > > > > From: linux-acpi-owner@vger.kernel.org
> > > > > [mailto:linux-acpi-owner@vger.kernel.org] On Behalf Of Moore, Robert
> > > > > Sent: Saturday, September 27, 2008 12:49 AM
> > > > > To: Henrique de Moraes Holschuh
> > > > > Cc: linux-acpi@vger.kernel.org
> > > > > Subject: RE: iasl and SSDT disassembling limitations
> > > > >
> > > > > Yes, it should be possible, and it is on our list of things to look
> > > > > at.
> > > > >
> > > > > A little more info on the problem: Without the definition of the
> > > > > control method, the disassembler has no way of knowing how many
> > > > > arguments should be passed to the method. Without this information,
> > > > > it does not know how many expressions to parse after the control
> > > > > method invocation in order to create the arguments. The information
> > > > > is simply not available. So it tries to guess.
> > > > >
> > > > > Bob
> > > > >
> > > > > >-----Original Message-----
> > > > > >From: Henrique de Moraes Holschuh [mailto:hmh@hmh.eng.br]
> > > > > >Sent: Friday, September 26, 2008 9:09 AM
> > > > > >To: Moore, Robert
> > > > > >Cc: linux-acpi@vger.kernel.org
> > > > > >Subject: iasl and SSDT disassembling limitations
> > > > > >
> > > > > >On Fri, 26 Sep 2008, Moore, Robert wrote:
> > > > > >> Most of the problems seen in the SSDT are related to the fact that
> > > > > >> the disassembler cannot always correctly disassemble code that
> > > > > >> contains calls to control methods that are external to the table.
> > > > > >> There is not enough information to disassemble correctly, and the
> > > > > >> table often needs to be repaired by hand.
> > > > > >
> > > > > >Can iasl be improved to properly disassemble such tables if we give
> > > > > > it ALL tables to work with?
> > > > > >
> > > > > >--
> > > > > >  "One disk to rule them all, One disk to find them. One disk to
> > > > > > bring them all and in the darkness grind them. In the Land of
> > > > > > Redmond where the shadows lie." -- The Silicon Valley Tarot
> > > > > >  Henrique Holschuh
> > > > >
> > > > > --
> > > > > To unsubscribe from this list: send the line "unsubscribe linux-acpi"
> > > > > in the body of a message to majordomo@vger.kernel.org
> > > > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > > >
> > > > --
> > > > To unsubscribe from this list: send the line "unsubscribe linux-acpi"
> > > > in the body of a message to majordomo@vger.kernel.org
> > > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 

Re: iasl and SSDT disassembling limitations

[Lin Ming]

On Tue, 2008-11-18 at 15:53 +0800, Lin Ming wrote:
> On Sat, 2008-11-15 at 00:28 +0800, Thomas Renninger wrote:
> > On Thursday 13 November 2008 08:02:29 Lin Ming wrote:
> > > On Thu, 2008-11-13 at 08:17 +0800, Thomas Renninger wrote:
> > > > On Friday 24 October 2008 05:50:30 am Lin Ming wrote:
> > > > > We have added a "-e" option to iasl that include tables for external
> > > > > symbol resolution. See
> > > > > http://git.acpica.org/repos/?p=acpica.git;a=commitdiff;h=2f705a1b06109e
> > > > >12bd 2659d0e12215710a5622b7
> > > > >
> > > > >
> > > > > Example: To disassemble an SSDT with external symbols defined in DSDT:
> > > > >
> > > > > iasl -e dsdt.aml -d ssdt.aml
> > > >
> > > > I thought this option already existed for quite a while?
> > > > Did it get re-implemented?
> > >
> > > No, the original one is a NULL implementation.
> > It did not work, but it already remembered unresolved objects/functions and 
> > tried to resolve them correctly from the -e passed table.
> > Either this or I did mess up something completely when I played with that 
> > maybe a year ago.
> > 
> > >
> > > > IIRC I already saw references in both directions. SSDT is making use of
> > > > variables declared in the DSDT and vice versa (rare, but it can happen).
> > > >
> > > > IMO a proper long-term solution would be to be able to do:
> > > > iasl -d [DS]SDT*.dsl
> > > > iasl then parses every table, remembers unresolved objects and then goes
> > > > through these, once the last table got parsed.
> > > >
> > > > Probably one step harder to implement, do you think this is possible to
> > > > do or should such things be considered as BIOS implementation bugs?
> > >
> > > It's possible, but harder. External symbol is not a BIOS bug.
> > Do you plan to extend the functionality that external symbols can be
> > resolved in both directions, e.g. by passing all DSDT and SSDT tables:
> > iasl -d DSDT.dsl SSDT1.dsl SSDT2.dsl
> 
> Yes, both directions.

Sorry for my misunderstanding here.
No, currently I don't have this plan.
But it's a good idea, I'll put it in the to-do list.

Thanks,
Lin Ming

> 
> > I tried that unsuccessfully quite some time ago.
> 
> I have some patches here.
> You can try it again when next version of iasl is released.
> 
> Lin Ming
> 
> > Now one still has an overview how this could be done :)
> > iasl -e DSDT.dsl SSDTx.dsl
> > should now work in much more cases, but I fear there will be some which
> > are still not covered (if DSDT references variables declared in SSDTs).
> > 
> > > iasl tries to guess the arguments of external methods, and it success at
> > > most time (-e option is not needed).
> > >
> > > But sometimes it fails, and then you can use -e option to include the
> > > external tables to resolve the external symbols.
> > Yes, and having this working makes it possible to more reliably check
> > BIOSes against ASL syntax errors.
> > 
> > Thanks a lot for your efforts,
> > 
> >      Thomas
> > 
> > > Lin Ming
> > >
> > > > Thanks,
> > > >
> > > >       Thomas
> > > >
> > > > > Lin Ming
> > > > >
> > > > > > From: linux-acpi-owner@vger.kernel.org
> > > > > > [mailto:linux-acpi-owner@vger.kernel.org] On Behalf Of Moore, Robert
> > > > > > Sent: Saturday, September 27, 2008 12:49 AM
> > > > > > To: Henrique de Moraes Holschuh
> > > > > > Cc: linux-acpi@vger.kernel.org
> > > > > > Subject: RE: iasl and SSDT disassembling limitations
> > > > > >
> > > > > > Yes, it should be possible, and it is on our list of things to look
> > > > > > at.
> > > > > >
> > > > > > A little more info on the problem: Without the definition of the
> > > > > > control method, the disassembler has no way of knowing how many
> > > > > > arguments should be passed to the method. Without this information,
> > > > > > it does not know how many expressions to parse after the control
> > > > > > method invocation in order to create the arguments. The information
> > > > > > is simply not available. So it tries to guess.
> > > > > >
> > > > > > Bob
> > > > > >
> > > > > > >-----Original Message-----
> > > > > > >From: Henrique de Moraes Holschuh [mailto:hmh@hmh.eng.br]
> > > > > > >Sent: Friday, September 26, 2008 9:09 AM
> > > > > > >To: Moore, Robert
> > > > > > >Cc: linux-acpi@vger.kernel.org
> > > > > > >Subject: iasl and SSDT disassembling limitations
> > > > > > >
> > > > > > >On Fri, 26 Sep 2008, Moore, Robert wrote:
> > > > > > >> Most of the problems seen in the SSDT are related to the fact that
> > > > > > >> the disassembler cannot always correctly disassemble code that
> > > > > > >> contains calls to control methods that are external to the table.
> > > > > > >> There is not enough information to disassemble correctly, and the
> > > > > > >> table often needs to be repaired by hand.
> > > > > > >
> > > > > > >Can iasl be improved to properly disassemble such tables if we give
> > > > > > > it ALL tables to work with?
> > > > > > >
> > > > > > >--
> > > > > > >  "One disk to rule them all, One disk to find them. One disk to
> > > > > > > bring them all and in the darkness grind them. In the Land of
> > > > > > > Redmond where the shadows lie." -- The Silicon Valley Tarot
> > > > > > >  Henrique Holschuh
> > > > > >
> > > > > > --
> > > > > > To unsubscribe from this list: send the line "unsubscribe linux-acpi"
> > > > > > in the body of a message to majordomo@vger.kernel.org
> > > > > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > > > >
> > > > > --
> > > > > To unsubscribe from this list: send the line "unsubscribe linux-acpi"
> > > > > in the body of a message to majordomo@vger.kernel.org
> > > > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > 
> >