This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA/commit 3/3] fix internal_error during fork event handling.


On 06/14/2012 07:29 PM, Joel Brobecker wrote:
> 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), and there
> is therefore no regcache for that process.  This is what triggers the
> internal error.

Pedantically, the fact that there is no regcache is okay; regcache's
are created lazily, on demand.  The problem is that we can't create one,
because regcache's need an address space pointer, and when we go ask the
target for the address space with target_thread_address_space, we'll not
be able to determine one, because the inferior inferior is not in the
inferior list.

> 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.
>
> Same as patch #1: I feel sufficiently confident to self approve, but
> comments always welcome...
>
> ---

>  gdb/ia64-hpux-nat.c |   52 ++++++++++++++++++++++++++++++++++++++++++++++++--
>  1 files changed, 49 insertions(+), 3 deletions(-)
> 
> diff --git a/gdb/ia64-hpux-nat.c b/gdb/ia64-hpux-nat.c
> index 07a433e..014f571 100644
> --- a/gdb/ia64-hpux-nat.c
> +++ b/gdb/ia64-hpux-nat.c
> @@ -485,6 +485,37 @@ ia64_hpux_xfer_memory_bs (struct target_ops *ops, const char *annex,
>      return 0;
>  }
>  
> +/* Get a register value as a unsigned value directly from the system,
> +   instead of going through the regcache.
> +
> +   This function is meant to work when there is no regcache, or even
> +   when inferior_ptid is not a thread/process known to GDB.  */
> +


"when there no regcache" here is therefore not really correct.
I'd just remove that bit and go with the simpler:

   This function is meant to be used when inferior_ptid is not
   a thread/process known to GDB.  */

> +static ULONGEST
> +ia64_hpux_get_register_from_save_state_t (int regnum, int reg_size)
> +{


This bypassing of the regcache would be troublesome for pseudo
registers, but if that's not a problem here, then this is fine with
me until we have a more general fix.

-- 
Pedro Alves


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]