From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Mon, 8 Feb 2016 13:55:10 -0700 Subject: [U-Boot] test/py: support running sandbox under gdbserver In-Reply-To: <20160208204929.GC25786@bill-the-cat> References: <1454627510-30981-1-git-send-email-swarren@wwwdotorg.org> <20160208204929.GC25786@bill-the-cat> Message-ID: <56B900AE.2080705@wwwdotorg.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 >> >> 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 > > Applied to u-boot/master, thanks! Oh. I was just about to send V2 to address some of Simon's comments...