[U-Boot] test/py: support running sandbox under gdbserver

[Tom Rini <trini@konsulko.com>]

On Thu, Feb 04, 2016 at 04:11:50PM -0700, Stephen Warren wrote:

> From: Stephen Warren <swarren@nvidia.com>
> 
> Implement command--line option --gdbserver COMM, which does two things:
> 
> a) Run the sandbox process under gdbserver, using COMM as gdbserver's
>    communication channel.
> 
> b) Disables all timeouts, so that if U-Boot is halted under the debugger,
>    tests don't fail. If the user gives up in the middle of a debugging
>    session, they can simply CTRL-C the test script to abort it.
> 
> This allows easy debugging of test failures without having to manually
> re-create the failure conditions. Usage is:
> 
> Window 1:
> ./test/py/test.py --bd sandbox --gdbserver localhost:1234
> 
> Window 2:
> gdb ./build-sandbox/u-boot -ex 'target remote localhost:1234'
> 
> When using this option, it likely makes sense to use pytest's -k option
> to limit the set of tests that are executed.
> 
> Simply running U-Boot directly under gdb (rather than gdbserver) was
> also considered. However, this was rejected because:
> 
> a) gdb's output would then be processed by the test script, and likely
>    confuse it causing false failures.
> 
> b) pytest by default hides stdout from tests, which would prevent the
>    user from interacting with gdb.
> 
>    While gdb can be told to redirect the debugee's stdio to a separate
>    PTY, this would appear to leave gdb's stdio directed at the test
>    scripts and the debugee's stdio directed elsewhere, which is the
>    opposite of the desired effect. Perhaps some complicated PTY muxing
>    and process hierarchy could invert this. However, the current scheme
>    is simple to implement and use, so it doesn't seem worth complicating
>    matters.
> 
> c) Using gdbserver allows arbitrary debuggers to be used, even those with
>    a GUI. If the test scripts invoked the debugger themselves, they'd have
>    to know how to execute arbitary applications. While the user could hide
>    this all in a wrapper script, this feels like extra complication.
> 
> An interesting future idea might be a --gdb-screen option, which could
> spawn both U-Boot and gdb separately, and spawn the screen into a newly
> created window under screen. Similar options could be envisaged for
> creating a new xterm/... too.
> 
> --gdbserver  currently only supports sandbox, and not real hardware.
> That's primarily because the test hooks are responsible for all aspects of
> hardware control, so there's nothing for the test scripts themselves can
> do to enable gdbserver on real hardware. We might consider introducing a
> separate --disable-timeouts option to support use of debuggers on real
> hardware, and having --gdbserver imply that option.
> 
> Signed-off-by: Stephen Warren <swarren@nvidia.com>

Applied to u-boot/master, thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160208/036ee7d9/attachment.sig>