Binutils with MCST patches
e390720bdc
Some test fails in gdb.reverse/break-reverse.exp on arm-linux lead me seeing the following error message, continue^M Continuing.^M Cannot remove breakpoints because program is no longer writable.^M ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Further execution is probably impossible.^M ^M Breakpoint 3, bar () at /home/yao/SourceCode/gnu/gdb/git/gdb/testsuite/gdb.reverse/break-reverse.c:22^M 22 xyz = 2; /* break in bar */^M (gdb) PASS: gdb.reverse/break-reverse.exp: continue to breakpoint: bar backward this is caused by two entries in record_full_breakpoints, and their addr is the same, but in_target_beneath is different. during the record, we do continue, Continuing. infrun: clear_proceed_status_thread (Thread 13772.13772) infrun: proceed (addr=0xffffffff, signal=GDB_SIGNAL_DEFAULT) infrun: step-over queue now empty infrun: resuming [Thread 13772.13772] for step-over infrun: skipping breakpoint: stepping past insn at: 0x8620 Sending packet: $Z0,85f4,4#1d...Packet received: OK <---- ..... Sending packet: $vCont;c#a8...infrun: target_wait (-1.0.0, status) = infrun: -1.0.0 [process -1], infrun: status->kind = ignore infrun: TARGET_WAITKIND_IGNORE infrun: prepare_to_wait infrun: target_wait (-1.0.0, status) = infrun: -1.0.0 [process -1], infrun: status->kind = ignore infrun: TARGET_WAITKIND_IGNORE infrun: prepare_to_wait Packet received: T05swbreak:;0b:9cf5ffbe;0d:9cf5ffbe;0f:f4850000;thread:p35cc.35cc;core:1; Sending packet: $Z0,85f4,4#1d...Packet received: OK <----- .... Sending packet: $z0,85f4,4#3d...Packet received: OK <----- we can see breakpoint on 0x85f4 are inserted *twice*, but only removed once. That is fine to remote target, because Z/z packets are idempotent, but there is a leftover in record_full_breakpoints in record-full target. The flow can be described as below, record_full_breakpoints remote target ----------------------------------------------------------------------- forward execution, continue, in_target_beneath 1 breakpoint inserted insert breakpoints on 0x85f4 in_target_beneath 1 twice program stops, remove breakpoint on 0x85f4 in_target_beneath 1 breakpoint removed reverse execution, continue, in_target_beneath 1 none is requested insert breakpoints on 0x85f4, in_target_beneath 0 program stops, remote breakpoint on 0x85f4, in_target_beneath 0 request to remove, but GDBserver doesn't know now, the question is why breakoint on 0x85f4 is inserted twice? One is the normal breakpoint, and the other is the single step breakpoint. GDB inserts single step breakpoint to do single step. When program stops at 0x85f4, both of them are set on 0x85f4, and GDB deletes single step breakpoint, so in update_global_location_list, this breakpoint location is no longer found, GDB call force_breakpoint_reinsertion to mark it condition_updated, and insert it again. The reason force_breakpoint_reinsertion is called to update the conditions in the target side, because the conditions may be changed. My original fix is to not call force_breakpoint_reinsertion if OLD_LOC->cond is NULL, but it is not correct if another location on the same address has condition, GDB doesn't produce condition for target side, but GDB should do. Then, I change my mind back to make record-full handling breakpoint idempotent, to align with remote target. Before insert a new entry into record_full_breakpoints, look for existing one on the same address first. I also add an assert on "bp->in_target_beneath == in_target_beneath", to be safer. gdb: 2016-04-07 Yao Qi <yao.qi@linaro.org> * record-full.c (record_full_insert_breakpoint): Return early if entry on the address is found in record_full_breakpoints. |
||
---|---|---|
bfd | ||
binutils | ||
config | ||
cpu | ||
elfcpp | ||
etc | ||
gas | ||
gdb | ||
gold | ||
gprof | ||
include | ||
intl | ||
ld | ||
libdecnumber | ||
libiberty | ||
opcodes | ||
readline | ||
sim | ||
texinfo | ||
zlib | ||
.cvsignore | ||
.gitattributes | ||
.gitignore | ||
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 | ||
README | ||
README-maintainer-mode | ||
setup.com | ||
src-release.sh | ||
symlink-tree | ||
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.