Subject: Re: gdb5.3 and thread support
To: Martin Husemann <martin@duskware.de>
From: Ian Lance Taylor <ian@wasabisystems.com>
List: tech-toolchain
Date: 09/15/2003 01:04:18
Martin Husemann <martin@duskware.de> writes:

> Could someone with more gdb clue than me please verify the thread-support code?
> Apparently only i386 has it in gdb5.3 now, and it's not clear to me how it
> should be rolled forward from the previous changes.
> 
> Looking for example at sparcnbsd-nat.c there is a prominent comment:
> 
> /* NOTE: We don't bother with any of the deferred_store nonsense; it
>    makes things a lot more complicated than they need to be.  */
> 
> IIUC the old thread support code just calls "the defered_store nonsense",
> and now the calls need to be changed to sparcnbsd_fill_reg32 and 
> sparcnbsd_supply_reg32 calls (and friends) - but how?

My understanding is that the thread code in nbsd-thread.c expects to
be able to call these functions:

void nbsd_reg_to_internal(struct reg *)
  Set internal register cache to values fetched from thread.
nbsd_fpreg_to_internal(struct fpreg *)
  Likewise for floating point registers.
nbsd_internal_to_reg(struct reg *)
  Fetch internal register cache.
nbsd_internal_to_fpreg(struct fpreg *)
  Likewise for floating point registers.

Deferred stores shouldn't be an issue here.  You just have to arrange
to write those functions, which can generally be implemented in terms
of the supply/fill functions which in gdb 5.3 be found in the *-tdep.c
files.

So, in sparcnbsd-nat.c, I think you need functions like these:

void
nbsd_reg_to_internal (regs)
     char *regs;
{
  sparcnbsd_supply_reg32 (regs, -1);
}

void
nbsd_fpreg_to_internal (fregs)
     char *fregs;
{
  sparcnbsd_supply_fpreg32 (fregs, -1);
}

void
nbsd_internal_to_reg (regs)
     char *regs;
{
  sparcnbsd_fill_reg32 (regs, -1);
}

void
nbsd_internal_to_fpreg (fregs)
     char *fregs;
{
  sparcnbsd_fill_fpreg32 (fregs, -1);
}

Mind you, I could be off-base here, and I certainly don't have any way
to test it.  But I think that is the general approach.

It would be more efficient to not have to fetch or store all the
registers at once.  Note that nbsd_thread_store_registers() and
nbsd_thread_fetch_registers() get a regno argument (which would be -1
to do all the registers).  But perhaps there is no interface similar
to td_thr_getregs() and td_thr_setregs() which works for only one
register.

sparcnbsd-nat.c also ought to have an implementation of
fetch_kcore_registers(), at least if you want to be able to use
`target kcore'.  There is one in the old gnu/dist/toolchain/gdb
sources; I don't know if it still works in gdb 5.3.

Ian