Re: [PATCH v2 4/5] Eliminate spurious warnings from remote exec

[Pedro Alves <palves@redhat.com>]

On 07/31/2015 12:19 AM, Don Breazeal wrote:
> This patch is unchanged from the previous version.
> 
> -----
> 
> This patch eliminates some spurious gdbserver warnings that occur when
> following an exec event on extended-remote Linux targets.
> 
> When gdbserver on Linux sets up the hook for shared library load
> detection, an initial step is to read the version number field of the
> r_debug structure from memory.  In the current implementation, if the
> version number is not equal to one, a warning is printed by gdbserver.
> However, the number can be zero if the structure has not been 
> initialized yet.  This seems to happen most of the time after an exec.

I wonder how come this doesn't trigger right after connection
with "target remote"?

> 
> To suppress the warnings the error check was changed so that if
> the version number is not equal to one the function silently returns
> -1.  Subsequent calls to the routine find an initialized r_debug
> structure.
> 
> Tested on x86_64 GNU/Linux, both GDB tests and manual testing which
> followed an exec, then debugged a shared library loaded by the exec'd
> program to ensure that there were no warnings and that debugging shared
> libs was not adversely affected.
> 
> Thanks
> --Don
> 
> gdb/gdbserver/
> 2015-07-30  Don Breazeal  <donb@codesourcery.com>
> 
> 	* linux-low.c (linux_qxfer_libraries_svr4):
> 	Return silently on r_debug version error instead of
> 	printing a warning.
> 
> ---
>  gdb/gdbserver/linux-low.c | 20 ++++++++++++++++----
>  1 file changed, 16 insertions(+), 4 deletions(-)
> 
> diff --git a/gdb/gdbserver/linux-low.c b/gdb/gdbserver/linux-low.c
> index af4619f..c0770b8 100644
> --- a/gdb/gdbserver/linux-low.c
> +++ b/gdb/gdbserver/linux-low.c
> @@ -580,6 +580,7 @@ handle_extended_wait (struct lwp_info *event_lwp, int wstat)
>    else if (event == PTRACE_EVENT_EXEC && report_exec_events)
>      {
>        struct regcache *regcache;
> +      struct process_info *proc;
>  
>        if (debug_threads)
>  	{
> @@ -598,10 +599,15 @@ handle_extended_wait (struct lwp_info *event_lwp, int wstat)
>  
>        /* The new executable may be for a different architecture than
>  	 that of the execing process, so re-initialize the architecture.
> -	 The call to get_pc will refill the register cache.  */
> +	 The call to get_pc will refill the register cache.  Force re-
> +	 initialization of r_debug from the (possibly) different dynamic
> +	 loader.  */
>        linux_arch_setup_thread (event_thr);
>        event_lwp->stop_pc = get_pc (event_lwp);
> +      proc = get_thread_process (event_thr);
> +      proc->priv->r_debug = 0;

(you only mentioned doing this in an earlier patch, I believe.  The
changelog and commit logs of this patch don't mention this, only
the warning.)

Seems to be we should reset everything, not just r_debug.
E.g., priv->thread_db.  After the exec, the new program might
not even be threaded.  Thus we should probably call thread_db_mourn.
Also, the priv->arch_private bits -- those will hold debug registers
things, for watchpoints/hw-breakpoints.  So what happens if a process
that has watchpoints set, execs?  It would seem to me that we should
completely forget about the previous debug registers mirrors, etc.?
Also, what about breakpoints managed by gdbserver?  If they were
inserted at the time of the exec, mem-break.c will continue believing
they are still inserted.  That means that if GDB tries to insert another
breakpoint at the same address, gdbserver won't actually insert it.
And also, if gdb reads code where an old breakpoint is still marked
inserted, gdb reads back the old breakpoint's shadow, which doesn't make
sense any longer after the exec.

This comment in follow_exec in gdb puts it best:

  /* We've followed the inferior through an exec.  Therefore, the
     inferior has essentially been killed & reborn.  */

>  
> +      /* Save the event for reporting.  */

(this hunk also seems to belong in some other earlier patch.)

>        event_lwp->waitstatus.kind = TARGET_WAITKIND_EXECD;
>        event_lwp->waitstatus.value.execd_pathname
>  	= xstrdup (linux_proc_pid_to_exec_file (lwpid_of (event_thr)));
> @@ -6462,10 +6468,16 @@ linux_qxfer_libraries_svr4 (const char *annex, unsigned char *readbuf,
>  	{
>  	  if (linux_read_memory (priv->r_debug + lmo->r_version_offset,
>  				 (unsigned char *) &r_version,
> -				 sizeof (r_version)) != 0
> -	      || r_version != 1)
> +				 sizeof (r_version)) != 0)
> +	    warning ("error reading r_debug version from memory");
> +	  else if (r_version != 1)
>  	    {
> -	      warning ("unexpected r_debug version %d", r_version);
> +	      /* We expect version 1 for glibc.  If the version is incorrect,
> +		 it probably means that r_debug hasn't been initialized yet.
> +		 Just silently return an error.  We will try again in a
> +		 subsequent pass through here, e.g. at the next library load
> +		 event.  */
> +	      return -1;
>  	    }
>  	  else if (read_one_ptr (priv->r_debug + lmo->r_map_offset,
>  				 &lm_addr, ptr_size) != 0)
> 

Thanks,
Pedro Alves