summaryrefslogtreecommitdiffstats
path: root/lldb/packages/Python/lldbsuite/test/lldbtest_config.py
diff options
context:
space:
mode:
authorPavel Labath <labath@google.com>2017-07-11 10:38:40 +0000
committerPavel Labath <labath@google.com>2017-07-11 10:38:40 +0000
commit21a365ba593ebeac305f1cf12fc039676697ef08 (patch)
treef359f15e2f6ba29d2f822dd3a524a7b84e123657 /lldb/packages/Python/lldbsuite/test/lldbtest_config.py
parent6561f78b646f1f4c4bfcbe486df55399c51f3bbe (diff)
downloadbcm5719-llvm-21a365ba593ebeac305f1cf12fc039676697ef08.tar.gz
bcm5719-llvm-21a365ba593ebeac305f1cf12fc039676697ef08.zip
NativeProcessLinux: Fix handling of raise(SIGTRAP)
In NativeProcessLinux::MonitorSIGTRAP we were asserting that the si_code value is one of the codes we know about. However, that list was very incomplete -- for example, we were not handling SI_TKILL/SI_USER, generated by raise(SIGTRAP). A cursory examination show there are at least a dozen codes like these that an app can generate, and more can be added at any point. So, instead of trying to play catchup, I change the default behavior to treat an unknown si_code like an ordinary signal. The only reason we needed to inspect si_code in the first place is because watchpoint/breakpoints are notified as SIGTRAP, but we already know about those, and us starting to use a new debug event is far less likely than somebody introducing a new non-debug event. I add a test case to TestRaise to verify we are handling raise(SIGTRAP) in an application properly. llvm-svn: 307644
Diffstat (limited to 'lldb/packages/Python/lldbsuite/test/lldbtest_config.py')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud