Skip to content
Snippets Groups Projects
Select Git revision
  • master default protected
  • early-display
  • variant-emmc-nvme-boot
  • 2023-01-25
  • v3
  • variant-emmc-nvme-boot
  • 2020-06-01
7 results

conftest.py

Blame
  • Forked from Reform / reform-boundary-uboot
    16467 commits behind the upstream repository.
    • Stephen Warren's avatar
      89ab8410
      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
      History
      test/py: support running sandbox under gdbserver
      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>
    conftest.py 13.65 KiB