On Wed, 12 May 1999, John Birrell wrote:
> Doug Rabson wrote:
> > I think the only state which I need to know about is PS_DEAD. If we marked
> > dead threads in the public struct it might simplify things.
>
> You use PS_RUNNING too. We could just tie down those two as PS_DEAD = 0
> and PS_RUNNING
On Wed, 12 May 1999, Daniel Eischen wrote:
> John Birrell wrote:
> > Daniel Eischen wrote:
> > > Why don't we make a libc_r_db and provide the necessary interfaces to
> > > gdb from that instead of having gdb know about uthread internals?
> >
> > It would still mean that gdb would be linked to the
John Birrell wrote:
> Daniel Eischen wrote:
> > Why don't we make a libc_r_db and provide the necessary interfaces to
> > gdb from that instead of having gdb know about uthread internals?
>
> It would still mean that gdb would be linked to the uthread internals
> which may not match the version of
Daniel Eischen wrote:
> Why don't we make a libc_r_db and provide the necessary interfaces to
> gdb from that instead of having gdb know about uthread internals?
It would still mean that gdb would be linked to the uthread internals
which may not match the version of libc_r that the 3rd party progr
John Birrell wrote:
> Doug Rabson wrote:
> > Other gdb thread debugging systems tend to export a set of variables from
> > the thread library which describe the important offsets in the thread
> > structure e.g. _debug_pthread_status_offset, _debug_pthread_foo_offset
> > etc.
>
> > If you think the
Doug Rabson wrote:
> I think the only state which I need to know about is PS_DEAD. If we marked
> dead threads in the public struct it might simplify things.
You use PS_RUNNING too. We could just tie down those two as PS_DEAD = 0
and PS_RUNNING = 1.
--
John Birrell - j...@cimlogic.com.au; j...@f
On Wed, 12 May 1999, John Birrell wrote:
> Doug Rabson wrote:
> > Ok, I'll see about updating my patch along these lines and I'll post up
> > another one in a day or two.
>
> One more thing... the states are subject to change, probably with new
> states being added. It is important to check that
Doug Rabson wrote:
> Ok, I'll see about updating my patch along these lines and I'll post up
> another one in a day or two.
One more thing... the states are subject to change, probably with new
states being added. It is important to check that the state number is
within the range that gdb was comp
On Wed, 12 May 1999, John Birrell wrote:
> Doug Rabson wrote:
> > That would work. I think I only need uniqueid, sig_saved,
> > saved_sigcontext, saved_jmpbuf, state and nxt. If those guys were lumped
> > up at the start of struct pthread (possibly in another struct so that gdb
> > doesn't need to
Doug Rabson wrote:
> That would work. I think I only need uniqueid, sig_saved,
> saved_sigcontext, saved_jmpbuf, state and nxt. If those guys were lumped
> up at the start of struct pthread (possibly in another struct so that gdb
> doesn't need to know sizeof(struct pthread)) and marked appropriate
On Wed, 12 May 1999, John Birrell wrote:
> Doug Rabson wrote:
> > Other gdb thread debugging systems tend to export a set of variables from
> > the thread library which describe the important offsets in the thread
> > structure e.g. _debug_pthread_status_offset, _debug_pthread_foo_offset
> > etc.
Doug Rabson wrote:
> Other gdb thread debugging systems tend to export a set of variables from
> the thread library which describe the important offsets in the thread
> structure e.g. _debug_pthread_status_offset, _debug_pthread_foo_offset
> etc.
>
> If you think there will be a real problem, I co
On Wed, 12 May 1999, John Birrell wrote:
> Doug Rabson wrote:
> > I didn't want to use the address since it might cause confusion if a
> > thread was freed and then the memory was re-allocated to create a new
> > thread.
>
> Good reason.
>
> > I thought about the versioning but I don't think it
Doug Rabson wrote:
> I didn't want to use the address since it might cause confusion if a
> thread was freed and then the memory was re-allocated to create a new
> thread.
Good reason.
> I thought about the versioning but I don't think it will be a problem in
> practice since both uthread and gdb
On Wed, 12 May 1999, John Birrell wrote:
> Doug Rabson wrote:
> > I've put an initial version of my hack for debugging FreeBSD user threads
> > with gdb up on http://www.freebsd.org/~dfr/uthread.diff. Comments would be
> > appreciated.
>
> Is the uniqueid really necessary when the address of the
Doug Rabson wrote:
> I've put an initial version of my hack for debugging FreeBSD user threads
> with gdb up on http://www.freebsd.org/~dfr/uthread.diff. Comments would be
> appreciated.
Is the uniqueid really necessary when the address of the thread structure
is already unique within the process
16 matches
Mail list logo
