gdb/
* infrun.c (_initialize_infrun) <handle command help text>:
Mention that multiple signals are supported.
gdb/testsuite/
* gdb.base/help.exp: Adjust to "handle" help text change.
Python interactive prompt with "pi" as alias, and add "py" as
an alias to "python".
* NEWS: Mention the new commands.
* doc/gdb.texinfo (Python Commands): Document the new
commands.
* python/python.c (eval_python_command): New function.
(python_interactive_command): For "python-interactive" with
arguments, call eval_python_command. For "python-interactive"
without arguments, call PyRun_InteractiveLoop.
(_initialize_python): Add "python-interactive" command with
"pi" as alias, and add "py" as an alias to "python".
* c-typeprint.c (c_type_print_varspec_prefix): Pass
-1 for SHOW to c_type_print_base for METHODPTR and MEMBERPTR.
* gdb.dwarf2/dw2-anon-mptr.exp: New file.
* gdb.dwarf2/dw2-anon-mptr.S: New file.
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.
Before this change, detach_breakpoints would take a pid, and then
set inferior_ptid to a ptid that it constructs using pid_to_ptid (pid).
Unfortunately, this ptid is not necessarily valid. Consider for
instance the case of ia64-hpux, where ttrace refuses a register-read
operation if the LWP is not provided.
This problems shows up when GDB is trying to handle fork events.
Assuming GDB is configured to follow the parent, GDB will try to
detach from the child. But before doing so, it needs to remove
all breakpoints inside that child. On ia64, this involves reading
inferior (the child's) memory. And on ia64-hpux, reading memory
requires us to read the bsp and bspstore registers, in order to
determine where that memory is relative to the value of those
registers, and thus to determine which ttrace operation to use in
order to fetch that memory (see ia64_hpux_xfer_memory).
This patch therefore changes detach_breakpoints to take a ptid instead
of a pid, and then updates all callers.
One of the consequences of this patch is that it trips an assert
on GNU/Linux targets. But this assert appears to have not actual
purpose, and is thus removed.
gdb/ChangeLog:
* breakpoint.h (detach_breakpoints): pid parameter is now a ptid.
* breakpoint.c (detach_breakpoints): Change pid parameter into
a ptid. Adjust code accordingly.
* infrun.c (handle_inferior_event): Delete variable child_pid.
Update call to detach_breakpoints to pass the child ptid for
fork events.
* linux-nat.c (linux_nat_iterate_watchpoint_lwps): Remove
assert that inferior_ptid's lwp is zero.
(linux_handle_extended_wait): Update call to detach_breakpoints.
* inf-ttrace.c (inf_ttrace_follow_fork): Update call to
detach_breakpoints.
When debugging a program that forks with follow-fork set to follow
the parent, we end up calling detach_breakpoints for the child twice.
On ia64-hpux, this leads to a warning when trying to remove the
breakpoints the second time around, because the ia64 code detects
that the address does not point to a breakpoint instruction.
gdb/ChangeLog:
* inf-ttrace.c (inf_ttrace_follow_fork): When following the
parent, only call detach_breakpoints if tts.tts_event ==
TTEVT_VFORK.
The problem is trying to unwind from a function where %ebp is NOT
used as the frame pointer, and the size of the frame changes over
the lifetime of that function.
For instance, trying to unwind past the GNAT runtime function
called system.tasking.rendezvous.timed_selective_wait on x86-linux,
one can get:
(gdb) bt
[...]
#3 0x0805364b in system.tasking.rendezvous.timed_selective_wait ()
#4 0xb7fe5068 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
Looking at the CFI, we find the following initial instructions...
> DW_CFA_def_cfa: %esp+4 (r4 ofs 4)
> DW_CFA_offset: %eip at cfa-4 (r8 = %eip)
... and the associated FDE:
> 00001be4 00000054 00001be8 FDE cie=00000000 pc=08053310..08053951
[...]
> DW_CFA_advance_loc: 8 to 080534ad
> DW_CFA_def_cfa_offset: 112
> DW_CFA_advance_loc2: 414 to 0805364b
> DW_CFA_def_cfa_offset: 108
[...]
The problem is that the DWARF frame unwinder executed the FDE until
the row for PC == 0x0805364b. But in reality, our program hasn't
executed the instruction at that address yet (it is the return address).
So GDB executed a little too much of the FDE, giving us the wrong
offset for the frame base, and thus the wrong address where %eip
got saved.
This patch fixes the problem by using a more correct PC as the bound
for executing the FDE.
gdb/ChangeLog:
* dwarf2-frame.c (dwarf2_frame_cache): Use
get_frame_address_in_block instead of get_frame_pc as
the bound for executing the frame's FDE.
gdb/testsuite/ChangeLog:
* gdb.ada/rdv_wait: New testcase.
