Skip to content
Snippets Groups Projects
  1. Oct 14, 2016
  2. Feb 08, 2016
    • Stephen Warren's avatar
      test/py: support running sandbox under gdbserver · 89ab8410
      Stephen Warren authored
      
      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: default avatarStephen Warren <swarren@nvidia.com>
      89ab8410
  3. Jan 29, 2016
    • Stephen Warren's avatar
      test/py: use " for docstrings · e8debf39
      Stephen Warren authored
      
      Python's coding style docs indicate to use " not ' for docstrings.
      
      test/py has other violations of the coding style docs, since the docs
      specify a stranger style than I would expect, but nobody has complained
      about those yet:-)
      
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      Reviewed-by: default avatarSimon Glass <sjg@chromium.org>
      e8debf39
    • Stephen Warren's avatar
      test/py: move U-Boot respawn trigger to the test core · 636f38d8
      Stephen Warren authored
      
      Prior to this change, U-Boot was lazilly (re-)spawned if/when a test
      attempted to interact with it, and no active connection existed. This
      approach was simple, yet had the disadvantage that U-Boot might be
      spawned in the middle of a test function, e.g. after the test had already
      performed actions such as creating data files, etc. In that case, this
      could cause the log to contain the sequence (1) some test logs, (2)
      U-Boot's boot process, (3) the rest of that test's logs. This isn't
      optimally readable. This issue will affect the upcoming DFU and enhanced
      UMS tests.
      
      This change converts u_boot_console to be a function-scoped fixture, so
      that pytest attempts to re-create the object for each test invocation.
      This allows the fixture factory function to ensure that U-Boot is spawned
      prior to every test. In practice, the same object is returned each time
      so there is essentially no additional overhead due to this change.
      
      This allows us to remove:
      
      - The explicit ensure_spawned() call from test_sleep, since the core now
      ensures that the spawn happens before the test code is executed.
      
      - The laxy calls to ensure_spawned() in the u_boot_console_*
      implementations.
      
      The one downside is that test_env's "state_ttest_env" fixture must be
      converted to a function-scoped fixture too, since a module-scoped fixture
      cannot use a function-scoped fixture. To avoid overhead, we use the same
      trick of returning the same object each time.
      
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      Acked-by: default avatarSimon Glass <sjg@chromium.org>
      636f38d8
  4. Jan 21, 2016
Loading