[rfc/rft] [3/5] Untangle register_addr: CANNOT_FETCH/STORE_REGISTER
Ulrich Weigand
uweigand@de.ibm.com
Mon Apr 16 16:03:00 GMT 2007
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
More information about the Gdb-patches
mailing list