Re: [rfc/rft] [3/5] Untangle register_addr: CANNOT_FETCH/STORE_REGISTER

["Ulrich Weigand" <uweigand@de.ibm.com>]

Mark Kettenis wrote:

> So effectively, this turns CANNOT_FETCH_REGISTER/CANNOT_STORE_REGISTER
> from being overloaded as both a native and target property into a
> target-architecture-only property instead.  That's probably a good
> idea.

Yes, that's certainly a main point of this.  Having an NM file provide
an override definition of a gdbarch routine is quite broken and prevents
further multi-arch conversion -- fortunately the mips-linux definition
of CANNOT_FETCH_REGISTER/CANNOT_STORE_REGISTER is the last remaining
instance of this.

> However, I think you removing the calls from the calls from the
> inf_ptrace_trad_target routines is wrong.  We should never fetch/store
> the registers for which the target architecture says that they cannot
> be fetched/stored.

Hmmm.  The reason why I did it this way was that I found it odd
for a native target fetch_registers routine to have to rely on
a gdbarch routine to make that determination.

Say, suppose on a target some register cannot be fetched (or stored)
by ptrace due to some limitation, but that same register may very well
be accessible via a remote stub.  In that case, it is not really a
gdbarch property that the register isn't accessible, but should be
handled solely within the native target code.

Now, a native target that simply provides its own fetch_registers
/ store_registers *is* of course free to implement such rules on
its own.  My patch simply makes that same set of choices available
to native targets that avail themselves of the inf_trad_ptrace
helpers.


Longer term, I would even think that the gdbarch cannot_store_register
and cannot_fetch_register routines could be completely obsoleted --
the per-target aspects should be handled by each target itself,
and the remaining per-architecture aspects could be covered by the
reggroup mechanism (in particular fetch_reggroup / store_reggroup).

But maybe this (if it should be the right direction anyway) should
be left to another patch, and not intermixed with the other set
of changes ...

> If you leave them in, do any targets remain that have any registers
> that can be fetched but cannot be stored by ptrace(2), that are not
> defined as such by the target architecture.  I'd be surprised if there
> were any such registers.

Well, there is the problem on mips-linux, because cannot_fetch is
different from cannot_store there.

However, as an intermediate step I could install the mips-linux
functions as Linux-specific gdbarch callbacks instead of NM file
overrides.  That would affect cross-debugging too, though ...

Bye,
Ulrich


-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com