This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: RFA: assert that target_fetch_registers did its job
- From: Daniel Jacobowitz <drow at false dot org>
- To: Jim Blandy <jimb at redhat dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Fri, 23 Jul 2004 20:44:33 -0400
- Subject: Re: RFA: assert that target_fetch_registers did its job
- References: <vt2oem6tjnk.fsf@zenia.home>
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;
if we need to relax it while some broken target is worked on, then
it should be a warning or silent.
> 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.
--
Daniel Jacobowitz