public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: Thomas Renninger <trenn@suse.de>
To: Lin Ming <ming.m.lin@intel.com>
Cc: linux-acpi <linux-acpi@vger.kernel.org>,
	hmh@hmh.eng.br, elendil@planet.nl, devel@lists.acpica.org
Subject: Re: iasl and SSDT disassembling limitations
Date: Wed, 12 Nov 2008 18:17:21 -0600	[thread overview]
Message-ID: <200811121817.22589.trenn@suse.de> (raw)
In-Reply-To: <1224845430.14280.58.camel@minggr.sh.intel.com>

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



  parent reply	other threads:[~2008-11-13  0:17 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <3515468CA27A0F49917112E2ECF61E210927CBF912@pdsmsx502.ccr.corp.intel.com>
2008-10-24 10:50 ` iasl and SSDT disassembling limitations Lin Ming
2008-10-30  9:11   ` Frans Pop
2008-10-30  9:16     ` Lin Ming
2008-11-13  0:17   ` Thomas Renninger [this message]
2008-11-13  7:02     ` Lin Ming
2008-11-14 16:28       ` Thomas Renninger
2008-11-18  7:53         ` Lin Ming
2008-11-18  8:00           ` Lin Ming
2008-09-25  9:19 Syntax errors in SSDT1 table of HP 2510p laptop Frans Pop
2008-09-26  3:44 ` Zhao Yakui
2008-09-26  4:52   ` Frans Pop
2008-09-26 13:37     ` Moore, Robert
2008-09-26 16:08       ` iasl and SSDT disassembling limitations Henrique de Moraes Holschuh
2008-09-26 16:48         ` Moore, Robert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200811121817.22589.trenn@suse.de \
    --to=trenn@suse.de \
    --cc=devel@lists.acpica.org \
    --cc=elendil@planet.nl \
    --cc=hmh@hmh.eng.br \
    --cc=linux-acpi@vger.kernel.org \
    --cc=ming.m.lin@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox