Re: [PATCH v4 2/2] gdb: raise and handle NOT_AVAILABLE_ERROR when accessing frame PC

[Eli Zaretskii <eliz@gnu.org>]

> Date: Wed, 20 Dec 2023 14:00:03 -0800
> From: John Baldwin <jhb@FreeBSD.org>
> 
> > --- a/gdb/amd64-linux-nat.c
> > +++ b/gdb/amd64-linux-nat.c
> > @@ -223,7 +223,10 @@ amd64_linux_nat_target::fetch_registers (struct regcache *regcache, int regnum)
> >         elf_gregset_t regs;
> >   
> >         if (ptrace (PTRACE_GETREGS, tid, 0, (long) &regs) < 0)
> > -	perror_with_name (_("Couldn't get registers"));
> > +	{
> > +	  std::string msg = perror_string (_("Couldn't get registers"));
> > +	  throw_error (NOT_AVAILABLE_ERROR, "%s", msg.c_str ());
> > +	}
> 
> Should other nat backends for other OS's (and other arches) also
> make this change when failing to fetch registers?

That's probably a good idea, yes.

But I also wonder whether the difference between

  Couldn't get registers: No such process.

or

  Could not read registers; remote failure reply 'E01'

and

  <PC register is not available>

or

  Backtrace stopped: not enough registers or memory available to unwind further

is such a significant improvement in terms of UX.  Both the "before"
and "after" messages allude to issues that are extremely technical and
obscure, IMO.  If anything, "No such process" sounds better to me than
"<PC register is not available>", because the former explicitly
explains the reason in high-level terms understood by anyone, while
the latter alludes to the PC register, which is a GDB abstraction, and
the fact that some register is not available doesn't necessarily tell
me what is wrong in practical terms.

IOW, it seems to me that, when we catch the error, we ought to produce
some meaningful message, and with this change we don't yet do that.

Does this make sense?