Re: RFA: assert that target_fetch_registers did its job

[Daniel Jacobowitz <drow@false.org>]

On Tue, Aug 03, 2004 at 08:36:04AM -0400, Andrew Cagney wrote:
> >On Fri, Jul 23, 2004 at 05:59:11PM -0500, Jim Blandy wrote:
> >>>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).

Everything I suggested in that paragraph was intended to live in the
GNU/Linux thread-db support, not in GDB core.  For GNU/Linux,
maintaining the politely broken fiction that one thread and one LWP are
not equivalent is not worthwhile any more.

Is there even a thread/lwp separation in GDB core?  My understanding
was that the core should never see anything having to do with an LWP;
at least the trivial LWP == thread mapping should have taken place
somewhere, and GDB should just talk to the threads.

-- 
Daniel Jacobowitz