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@xxxxxxxxxxxxxxx > > [mailto:linux-acpi-owner@xxxxxxxxxxxxxxx] On Behalf Of Moore, Robert > > Sent: Saturday, September 27, 2008 12:49 AM > > To: Henrique de Moraes Holschuh > > Cc: linux-acpi@xxxxxxxxxxxxxxx > > 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@xxxxxxxxxx] > > >Sent: Friday, September 26, 2008 9:09 AM > > >To: Moore, Robert > > >Cc: linux-acpi@xxxxxxxxxxxxxxx > > >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@xxxxxxxxxxxxxxx > > 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@xxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
