[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1AE640813FDE7649BE1B193DEA596E883BC0EB79@SHSMSX101.ccr.corp.intel.com>
Date: Wed, 17 Aug 2016 04:31:48 +0000
From: "Zheng, Lv" <lv.zheng@...el.com>
To: "Rafael J. Wysocki" <rjw@...ysocki.net>
CC: "Wysocki, Rafael J" <rafael.j.wysocki@...el.com>,
"Brown, Len" <len.brown@...el.com>, Lv Zheng <zetalog@...il.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>
Subject: RE: [PATCH v4 3/3] tools/power/acpi/acpidbg: Add multi-commands
support in batch mode
Hi, Rafael
> From: Rafael J. Wysocki [mailto:rjw@...ysocki.net]
> Subject: Re: [PATCH v4 3/3] tools/power/acpi/acpidbg: Add multi-commands support in batch mode
>
> On Tuesday, July 26, 2016 07:01:45 PM Lv Zheng wrote:
> > This patch adds multi-commands support for the batch mode. The same mode
> > can be seen in acpiexec.
> >
> > However people may think this is not useful for an in-kernel debugger,
> > because the in-kernel debugger is always running, never exits. So we can
> > run another command by running another acpidbg batch mode instance.
> >
> > But this mode should still be useful for acpidbg. The reason is: when the
> > in-kernel debugger has entered the single-stepping mode, ending acpidbg
> > (which closes the debugger IO interface) will lead to the end of the
> > single-stepping mode.
> >
> > So we need the acpidbg multi-commands batch mode in order to execute
> > multiple single-stepping mode commands in scripts.
>
> An example would be really useful here IMO.
Considering the following control method:
Name (TVAL, Zero)
Method (TMTD)
{
Inrement (TVAL)
}
When it is executed in acpiexec:
---
#!/bin/sh
acpiexec -b "ex \TMTD" -es dsdt.aml
acpiexec -b "ex \TVAL" -es dsdt.aml
---
The result is "0" for TVAL, because each acpiexec instance re-initializes the namespace.
Thus acpiexec provides a multi-command batch mode:
---
#!/bin/sh
acpiexec -b "ex \TMTD; ex \TVAL" -es dsdt.aml
---
The result is "1" now.
Then for this case (I'll use it to compare acpidbg behavior):
---
#!/bin/sh
acpiexec -b "ex \TMTD" -es dsdt.aml
acpiexec -b "ex \TMTD; ex \TVAL" -es dsdt.aml
---
The result is "1".
Unlike acpiexec, whatever the AML debugger is initialized/terminated.
The namespace won't be re-initialized.
So for the above cases:
---
#!/bin/sh
acpidbg -b "ex \TMTD"
acpidbg -b "ex \TVAL"
---
The result is "1".
---
#!/bin/sh
acpidbg -b "ex \TMTD"
acpidbg -b "ex \TMTD; ex \TVAL"
---
The result is "2", it should be no different than:
---
#!/bin/sh
acpidbg -b "ex \TMTD"
acpidbg -b "ex \TMTD"
acpidbg -b "ex \TVAL"
---
Thus I said:
People may think this (the multi-command support) is not useful for an in-kernel debugger.
But there is a special case for the single stepping mode.
---
#!/bin/sh
acpidbg -b "debug \TMTD"
acpidbg -b "locals"
---
The "debug" command is special, it puts AML debugger into single stepping mode.
In this mode, user can use single stepping mode commands to debug the evaluation of the TMTD.
The result of this script is:
There is no method currently executing.
Because for the kernel AML debugger, if we leave a \TMTD unfinished.
Then mutex held in this method could block normal kernel evaluations of the methods requiring same mutexes.
Thus if acpidbg exits (closing acpi_dbg IO), single stepping mode will also run into an end.
See:
acpi_terminate_debugger() in acpi_aml_release().
So we need the multi-command batch mode for this case:
---
#!/bin/sh
acpidbg -b "debug \TMTD; locals"
---
The result of this script is:
No Local Variables are initialized for method (TMTD)
Best regards
Lv
Powered by blists - more mailing lists