mirror of
https://github.com/espressif/binutils-gdb.git
synced 2025-06-22 19:09:31 +08:00
973e3cf70d
When running on ia64-hpux a program that calls fork, GDB currently
reports the following internal error:
internal-error: Can't determine the current address space of thread process 1882
Here is what happens:
1. GDB receives a "fork" event;
2. handle_inferior_event calls detach_breakpoints for the child process;
3. detach_breakpoints calls ia64's gdbarch remove_breakpoint hook,
which needs to read an entire instruction slot in order to remove
a breakpoint instruction from memory;
4. To read inferior memory, the ia64-hpux code needs to know where
that memory is located relative to the bsp..bspstore area,
and thus needs to read the value of those registers;
5. To get the value of those registers, ia64_hpux_xfer_memory current
uses the current regcache.
The problem is that at the time we are trying to remove the breakpoints
from the child, the child process is not part of the list of inferiors
really known to GDB (it has not been added to inferior_list), so trying
to create a regcache for it triggers an internal error when creating
address space for the regcache (as the address space is ultimately
fetched from the inferior).
To work around this limitation, ia64_hpux_xfer_memory has been modified
to detect the fact the current inferior is not in our inferior list,
and to go, in that case, straight to the source to fetch the registers
it needs.
gdb/ChangeLog:
* ia64-hpux-nat.c (ia64_hpux_get_register_from_save_state_t):
New function.
(ia64_hpux_xfer_memory): Check if inferior_ptid is known before
using the regache. Use ia64_hpux_get_register_from_save_state_t
to access the bsp and bspstore registers if not.
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.