[1/2] Fix PR gdb/19676: Disable displaced stepping if /proc not mounted

  On GNU/Linux archs that support displaced stepping, if /proc is not
mounted, GDB gets stuck not able to step past breakpoints:

 (gdb) c
 Continuing.
 dl_main (phdr=<optimized out>, phnum=<optimized out>, user_entry=<optimized out>, auxv=<optimized out>) at rtld.c:2163
 2163      LIBC_PROBE (init_complete, 2, LM_ID_BASE, r);
 Cannot find AT_ENTRY auxiliary vector entry.
 (gdb) c
 Continuing.
 dl_main (phdr=<optimized out>, phnum=<optimized out>, user_entry=<optimized out>, auxv=<optimized out>) at rtld.c:2163
 2163      LIBC_PROBE (init_complete, 2, LM_ID_BASE, r);
 Cannot find AT_ENTRY auxiliary vector entry.
 (gdb)

That's because GDB can't figure out where the scratch pad is.

This is a regression introduced by the earlier changes to make the
Linux native target always work in non-stop mode.

This commit makes GDB detect the case and fallback to stepping over
breakpoints in-line.

gdb/ChangeLog:
2016-03-01  Pedro Alves  <pedro@cascais.lan>

	PR gdb/19676
	* infrun.c (displaced_step_prepare): Also disable displaced
	stepping on NOT_SUPPORTED_ERROR.
	* linux-tdep.c (linux_displaced_step_location): If reading auxv
	fails, throw NOT_SUPPORTED_ERROR instead of generic error.
---
 gdb/infrun.c     | 3 ++-
 gdb/linux-tdep.c | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)
  

On 16-03-01 11:45 AM, Pedro Alves wrote:
> On GNU/Linux archs that support displaced stepping, if /proc is not
> mounted, GDB gets stuck not able to step past breakpoints:
> 
>  (gdb) c
>  Continuing.
>  dl_main (phdr=<optimized out>, phnum=<optimized out>, user_entry=<optimized out>, auxv=<optimized out>) at rtld.c:2163
>  2163      LIBC_PROBE (init_complete, 2, LM_ID_BASE, r);
>  Cannot find AT_ENTRY auxiliary vector entry.
>  (gdb) c
>  Continuing.
>  dl_main (phdr=<optimized out>, phnum=<optimized out>, user_entry=<optimized out>, auxv=<optimized out>) at rtld.c:2163
>  2163      LIBC_PROBE (init_complete, 2, LM_ID_BASE, r);
>  Cannot find AT_ENTRY auxiliary vector entry.
>  (gdb)
> 
> That's because GDB can't figure out where the scratch pad is.
> 
> This is a regression introduced by the earlier changes to make the
> Linux native target always work in non-stop mode.
> 
> This commit makes GDB detect the case and fallback to stepping over
> breakpoints in-line.
> 
> gdb/ChangeLog:
> 2016-03-01  Pedro Alves  <pedro@cascais.lan>
> 
> 	PR gdb/19676
> 	* infrun.c (displaced_step_prepare): Also disable displaced
> 	stepping on NOT_SUPPORTED_ERROR.
> 	* linux-tdep.c (linux_displaced_step_location): If reading auxv
> 	fails, throw NOT_SUPPORTED_ERROR instead of generic error.
> ---
>  gdb/infrun.c     | 3 ++-
>  gdb/linux-tdep.c | 3 ++-
>  2 files changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/gdb/infrun.c b/gdb/infrun.c
> index 3e8c9e0..696105d 100644
> --- a/gdb/infrun.c
> +++ b/gdb/infrun.c
> @@ -1894,7 +1894,8 @@ displaced_step_prepare (ptid_t ptid)
>      {
>        struct displaced_step_inferior_state *displaced_state;
>  
> -      if (ex.error != MEMORY_ERROR)
> +      if (ex.error != MEMORY_ERROR
> +	  && ex.error != NOT_SUPPORTED_ERROR)
>  	throw_exception (ex);
>  
>        if (debug_infrun)
> diff --git a/gdb/linux-tdep.c b/gdb/linux-tdep.c
> index 555c302..f197aa7 100644
> --- a/gdb/linux-tdep.c
> +++ b/gdb/linux-tdep.c
> @@ -2426,7 +2426,8 @@ linux_displaced_step_location (struct gdbarch *gdbarch)
>       location.  The auxiliary vector gets us the PowerPC-side entry
>       point address instead.  */
>    if (target_auxv_search (&current_target, AT_ENTRY, &addr) <= 0)
> -    error (_("Cannot find AT_ENTRY auxiliary vector entry."));
> +    throw_error (NOT_SUPPORTED_ERROR,
> +		 _("Cannot find AT_ENTRY auxiliary vector entry."));
>  
>    /* Make certain that the address points at real code, and not a
>       function descriptor.  */
> 

Whoa, I didn't even know you could run without proc.

You would probably have seen it anyway, but the email address in your
ChangeLog entries has a local host name.

Simon
  

On 03/01/2016 05:00 PM, Simon Marchi wrote:

> You would probably have seen it anyway, but the email address in your
> ChangeLog entries has a local host name.

Whoops, thanks.  :-)