mirror of
https://sourceware.org/git/binutils-gdb.git
synced 2024-12-15 04:31:49 +08:00
b94ade4284
As shown by the bug report, GDB crashes when the remote target was unable to write to a register (the program counter) with the 'P' packet. This was reported for AVR but can be reproduced on any architecture with a gdbserver that fails to handle a 'P' packet. Issue ===== This GDB session was done with a custom gdbserver patched to send an error packet when trying to set the program counter with a 'P' packet: ~~~ (gdb) file Debug/ATMega2560-simple-program.elf Reading symbols from Debug/ATMega2560-simple-program.elf...done. (gdb) target remote :51000 Remote debugging using :51000 0x00000000 in __vectors () (gdb) load Loading section .text, size 0x1fc lma 0x0 Start address 0x0, load size 508 Transfer rate: 248 KB/sec, 169 bytes/write. (gdb) b main Breakpoint 1 at 0x164: file .././ATMega2560-simple-program.c, line 39. (gdb) c Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. main () at .././ATMega2560-simple-program.c:42 42 DDRD |= LED0_MASK;// | LED1_MASK; (gdb) info line 43 Line 43 of ".././ATMega2560-simple-program.c" is at address 0x178 <main+40> but contains no code. (gdb) set $pc=0x178 Could not write register "PC2"; remote failure reply 'E00' (gdb) info registers pc pc 0x178 0x178 <main+40> (gdb) s ../../unisrc-mainline/gdb/infrun.c:1978: internal-error: resume: Assertion `pc_in_thread_step_range (pc, tp)' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) ../../unisrc-mainline/gdb/infrun.c:1978: internal-error: resume: Assertion `pc_in_thread_step_range (pc, tp)' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Create a core file of GDB? (y or n) ~~~ We can see that even though GDB reports that writing to the register failed, the register cache was updated: ~~~ (gdb) set $pc=0x178 Could not write register "PC2"; remote failure reply 'E00' (gdb) info registers pc pc 0x178 0x178 <main+40> ~~~ The root of the problem is of course in the gdbserver but I thought GDB should keep a register cache consistent with the hardware even in case of a failure. Changes ======= This patch adds routines to add a regcache_invalidate cleanup to the current chain. We can then register one before calling target_store_registers. This way if the target throws an error, the register we wanted to write to will be invalidated in cache. If target_store_registers succeeds, we can discard the new cleanup. 2014-06-12 Pierre Langlois <pierre.langlois@embecosm.com> * regcache.c (struct register_to_invalidate): New structure. (do_register_invalidate, make_cleanup_regcache_invalidate): New functions. (regcache_raw_write): Call make_cleanup_regcache_invalidate. |
||
|---|---|---|
| bfd | ||
| binutils | ||
| config | ||
| cpu | ||
| elfcpp | ||
| etc | ||
| gas | ||
| gdb | ||
| gold | ||
| gprof | ||
| include | ||
| intl | ||
| ld | ||
| libdecnumber | ||
| libiberty | ||
| opcodes | ||
| readline | ||
| sim | ||
| texinfo | ||
| .cvsignore | ||
| .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 | ||
| 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.