mirror of
https://sourceware.org/git/binutils-gdb.git
synced 2024-12-09 04:21:49 +08:00
64760036a8
[ Partial resubmission of an earlier submission by Andrew ( https://sourceware.org/pipermail/gdb-patches/2012-September/096347.html ), so listing him as co-author. ] With x86_64-linux and target board unix/-m32, we have: ... (gdb) continue^M Continuing.^M Exception #10^M ^M Breakpoint 3, throw_exception_1 (e=10) at py-finish-breakpoint2.cc:23^M 23 throw new int (e);^M (gdb) FAIL: gdb.python/py-finish-breakpoint2.exp: \ check FinishBreakpoint in catch() ... The following scenario happens: - set breakpoint in throw_exception_1, a function that throws an exception - continue - hit breakpoint, with call stack main.c:38 -> throw_exception_1 - set a finish breakpoint - continue - hit the breakpoint again, with call stack main.c:48 -> throw_exception -> throw_exception_1 Due to the exception, the function call did not properly terminate, and the finish breakpoint didn't trigger. This is expected behaviour. However, the intention is that gdb detects this situation at the next stop and calls the out_of_scope callback, which would result here in this test-case in a rather confusing "exception did not finish" message. So the problem is that this message doesn't show up, in other words, the out_of_scope callback is not called. [ Note that the fact that the situation is detected only at the next stop (wherever that happens to be) could be improved upon, and the earlier submission did that by setting a longjmp breakpoint. But I'm considering this problem out-of-scope for this patch. ] Note that the message does show up later, at thread exit: ... [Inferior 1 (process 20046) exited with code 0236]^M exception did not finish ...^M ... The decision on whether to call the out_of_scope call back is taken in bpfinishpy_detect_out_scope_cb, and the interesting bit is here: ... if (b->pspace == current_inferior ()->pspace && (!target_has_registers () || frame_find_by_id (b->frame_id) == NULL)) bpfinishpy_out_of_scope (finish_bp); ... In the case of the thread exit, the callback triggers because target_has_registers () == 0. So why doesn't the callback trigger in the case of the breakpoint? Well, the b->frame_id is the frame_id of the frame of main (the frame in which the finish breakpoint is supposed to trigger), so AFAIU frame_find_by_id (b->frame_id) == NULL will only be true once we've left main, at which point I guess we don't stop till thread exit. Fix this by saving the frame in which the finish breakpoint was created, and using frame_find_by_id () == NULL on that frame instead, such that we have: ... (gdb) continue^M Continuing.^M Exception #10^M ^M Breakpoint 3, throw_exception_1 (e=10) at py-finish-breakpoint2.cc:23^M 23 throw new int (e);^M exception did not finish ...^M (gdb) FAIL: gdb.python/py-finish-breakpoint2.exp: \ check FinishBreakpoint in catch() ... Still, the test-case is failing because it's setup to match the behaviour that we get on x86_64-linux with target board unix/-m64: ... (gdb) continue^M Continuing.^M Exception #10^M stopped at ExceptionFinishBreakpoint^M (gdb) PASS: gdb.python/py-finish-breakpoint2.exp: \ check FinishBreakpoint in catch() ... So what happens here? Again, due to the exception, the function call did not properly terminate, but the finish breakpoint still triggers. This is somewhat unexpected. This happens because it just so happens to be that the frame return address at which the breakpoint is set, is also the first instruction after the exception has been handled. This is a know problem, filed as PR29909, so KFAIL it, and modify the test-case to expect the out_of_scope callback. Also add a breakpoint after setting the finish breakpoint but before throwing the exception, to check that we don't call the out_of_scope callback too early. Tested on x86_64-linux, with target boards unix/-m32. Co-Authored-By: Andrew Burgess <aburgess@redhat.com> PR python/27247 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27247 |
||
|---|---|---|
| bfd | ||
| binutils | ||
| config | ||
| contrib | ||
| cpu | ||
| elfcpp | ||
| etc | ||
| gas | ||
| gdb | ||
| gdbserver | ||
| gdbsupport | ||
| gnulib | ||
| gold | ||
| gprof | ||
| gprofng | ||
| include | ||
| intl | ||
| ld | ||
| libbacktrace | ||
| libctf | ||
| libdecnumber | ||
| libiberty | ||
| libsframe | ||
| opcodes | ||
| readline | ||
| sim | ||
| texinfo | ||
| zlib | ||
| .cvsignore | ||
| .editorconfig | ||
| .gitattributes | ||
| .gitignore | ||
| ar-lib | ||
| ChangeLog | ||
| compile | ||
| config-ml.in | ||
| config.guess | ||
| config.rpath | ||
| config.sub | ||
| configure | ||
| configure.ac | ||
| COPYING | ||
| COPYING3 | ||
| COPYING3.LIB | ||
| COPYING.LIB | ||
| COPYING.LIBGLOSS | ||
| COPYING.NEWLIB | ||
| depcomp | ||
| djunpack.bat | ||
| install-sh | ||
| libtool.m4 | ||
| lt~obsolete.m4 | ||
| ltgcc.m4 | ||
| ltmain.sh | ||
| ltoptions.m4 | ||
| ltsugar.m4 | ||
| ltversion.m4 | ||
| MAINTAINERS | ||
| Makefile.def | ||
| Makefile.in | ||
| Makefile.tpl | ||
| makefile.vms | ||
| missing | ||
| mkdep | ||
| mkinstalldirs | ||
| move-if-change | ||
| multilib.am | ||
| README | ||
| README-maintainer-mode | ||
| setup.com | ||
| src-release.sh | ||
| symlink-tree | ||
| test-driver | ||
| ylwrap | ||
README for GNU development tools This directory contains various GNU compilers, assemblers, linkers, debuggers, etc., plus their support routines, definitions, and documentation. If you are receiving this as part of a GDB release, see the file gdb/README. If with a binutils release, see binutils/README; if with a libg++ release, see libg++/README, etc. That'll give you info about this package -- supported targets, how to use it, how to report bugs, etc. It is now possible to automatically configure and build a variety of tools with one command. To build all of the tools contained herein, run the ``configure'' script here, e.g.: ./configure make To install them (by default in /usr/local/bin, /usr/local/lib, etc), then do: make install (If the configure script can't determine your type of computer, give it the name as an argument, for instance ``./configure sun4''. You can use the script ``config.sub'' to test whether a name is recognized; if it is, config.sub translates it to a triplet specifying CPU, vendor, and OS.) If you have more than one compiler on your system, it is often best to explicitly set CC in the environment before running configure, and to also set CC when running make. For example (assuming sh/bash/ksh): CC=gcc ./configure make A similar example using csh: setenv CC gcc ./configure make Much of the code and documentation enclosed is copyright by the Free Software Foundation, Inc. See the file COPYING or COPYING.LIB in the various directories, for a description of the GNU General Public License terms under which you can copy the files. REPORTING BUGS: Again, see gdb/README, binutils/README, etc., for info on where and how to report problems.