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

[Tom Rini]

On Mon, Feb 08, 2016 at 01:55:10PM -0700, Stephen Warren wrote:
> On 02/08/2016 01:49 PM, Tom Rini wrote:
> >On Thu, Feb 04, 2016 at 04:11:50PM -0700, Stephen Warren wrote:
> >
> >>From: Stephen Warren <swarren at 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 at nvidia.com>
> >
> >Applied to u-boot/master, thanks!
> 
> Oh. I was just about to send V2 to address some of Simon's comments...

Feh.  Please send 'em as an iterative patch then :)

-- 
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/cc9d661d/attachment.sig>