Re: RFA: assert that target_fetch_registers did its job

[Andrew Cagney <cagney at gnu dot org>]

> On Fri, Jul 23, 2004 at 05:59:11PM -0500, Jim Blandy wrote:
>
> > > Does anyone see anything wrong with this?  Should it be an error, or a
> > > warning, instead of an internal error?  It seems to me that the error
> > > should be furnished by the target-specific code; if
> > > target_fetch_registers returns silently, it should have done its job.
>
>
> It shouldn't be an error.  internal-error makes the most sense to me;

Right, it's a contract between two internal parts of gdb.

> > > But thread_db_fetch_registers doesn't follow that assumption.  In the
> > > threaded case, given any register number, it fetches the gprs, and the
> > > fprs, supplies them, and assumes its job is done.  It seems to me it
> > > sholud be calling register_valid_p (current_regcache, regno) to check
> > > that the register's value has really been supplied, and complaining if
> > > it hasn't.
>
>
> I suggest we slay thread_db_fetch_registers.
>
> Once upon a time, it served a purpose.  Now it is nothing but a source
> of problems.  We could pass opaque cookies rather than register data
> through the gregset structure - the interface doesn't really support
> this but at least two of the five thread-db implementations I'm aware
> of would.  Or we could just give up, use thread-db for nothing besides
> finding new threads, and ask the LWP for its registers directly without
> six or eight call frames of indirection.

You're saying have GNU/Linux thread_db_fetch_regsters bypass libthread-db?

The thread-db can certainly take the shortest path to the registers. 
However, I'm not so sure about core GDB doing the bypass - it would 
violate the separation of thread and lwp (what little there is).

--

Looking at the internals of libthread-db, this looks like a strong 
motivation for introducing more explicit greg, fpreg, ... target_objects 
and fetching the values using that.

Andrew