aboutsummaryrefslogtreecommitdiff
path: root/gdb/testsuite/gdb.python/py-recurse-unwind.py
AgeCommit message (Collapse)AuthorFilesLines
2018-01-02Update copyright year range in all GDB filesJoel Brobecker1-1/+1
gdb/ChangeLog: Update copyright year range in all GDB files
2017-01-01update copyright year range in GDB filesJoel Brobecker1-1/+1
This applies the second part of GDB's End of Year Procedure, which updates the copyright year range in all of GDB's files. gdb/ChangeLog: Update copyright year range in all GDB files.
2016-11-16Extend test gdb.python/py-recurse-unwind.expKevin Buettner1-5/+24
This patch modifies the unwinder (sniffer) defined in py-recurse-unwind.py so that, depending upon the value of one of its class variables, it will take different paths through the code, testing different functionality. The original test attempted to obtain the value of an undefined symbol. This somewhat expanded test checks to see if 'pc' can be read via gdb.PendingFrame.read_register() and also via gdb.parse_and_eval(). gdb/testsuite/ChangeLog: * gdb.python/py-recurse-unwind.c (main): Add loop. * gdb.python/py-recurse-unwind.py (TestUnwinder): Add calls to read_register() and gdb.parse_and_eval(). Make each code call a separate case that can be individually tested. * gdb.python/py-recurse-unwind.exp (cont_and_backtrace): New proc. Call cont_and_backtrace for each of the code paths that we want to test in the unwinder.
2016-08-24Test case to detect recursive unwinding in Python-based unwinders.Kevin Buettner1-0/+68
This test case verifies that GDB will not attempt to invoke a python unwinder recursively. At the moment, the behavior exhibited by GDB looks like this: (gdb) source py-recurse-unwind.py Python script imported (gdb) b ccc Breakpoint 1 at 0x4004bd: file py-recurse-unwind.c, line 23. (gdb) run Starting program: py-recurse-unwind TestUnwinder: Recursion detected - returning early. TestUnwinder: Recursion detected - returning early. TestUnwinder: Recursion detected - returning early. TestUnwinder: Recursion detected - returning early. Breakpoint 1, ccc (arg=<unavailable>) at py-recurse-unwind.c:23 23 } (gdb) bt #-1 ccc (arg=<unavailable>) at py-recurse-unwind.c:23 Backtrace stopped: previous frame identical to this frame (corrupt stack?) [I've shortened pathnames for easier reading.] The desired / expected behavior looks like this: (gdb) source py-recurse-unwind.py Python script imported (gdb) b ccc Breakpoint 1 at 0x4004bd: file py-recurse-unwind.c, line 23. (gdb) run Starting program: py-recurse-unwind Breakpoint 1, ccc (arg=789) at py-recurse-unwind.c:23 23 } (gdb) bt #0 ccc (arg=789) at py-recurse-unwind.c:23 #1 0x00000000004004d5 in bbb (arg=456) at py-recurse-unwind.c:28 #2 0x00000000004004ed in aaa (arg=123) at py-recurse-unwind.c:34 #3 0x00000000004004fe in main () at py-recurse-unwind.c:40 Note that GDB's problems go well beyond the fact that it invokes the unwinder recursively. In the process it messes up some internal state (the frame stash) leading to display of (only) the sentinel frame in the backtrace. gdb/testsuite/ChangeLog: * gdb.python/py-recurse-unwind.c: New file. * gdb.python/py-recurse-unwind.py: New file. * gdb.python/py-recurse-unwind.exp: New file.