On Wed, 2019-10-30 at 16:49 -0700, Omar Sandoval wrote: > On Wed, Oct 30, 2019 at 01:47:52PM +0100, Mark Wielaard wrote: > > Also, if we would adopt dwfl_attach_thread then I think it should take > > a Dwfl_Thread object not a pid/tid as argument. > > In that case, we'd probably want to expose the internal getthread > function with something like: > > /* Find the thread with the given thread ID. Returns zero if the > thread was processed, -1 on error (including when no thread with the > given thread ID exists), or the return value of the callback when not > DWARF_CB_OK. */ > int dwfl_getthread (Dwfl *dwfl, pid_t tid, > int (*callback) (Dwfl_Thread *thread, void *arg), > void *arg) > __nonnull_attribute__ (1, 3); > > Then dwfl_attach_thread could be used with either dwfl_getthread or > dwfl_getthreads, which is nice. However, a crucial part of this > feature > is being able to access the Dwfl_Thread outside of the callback. > > Since > the Dwfl_Thread is currently on the stack, I see a couple of options: > > 1. We keep Dwfl_Thread on the stack and make dwfl_attach_thread() > return > a copy (like it does in this patch). > 2. We always allocate the Dwfl_Thread on the heap and free it before > returning from dwfl_getthread(s) _unless_ dwfl_attach_thread() was > called. If it was, it will be freed by dwfl_detach_thread() > instead. > > Option 2 sounds better to me. What do you think?
To be honest I am not sure I like either. I think it is mainly because this isn't really about attaching/detaching from a thread but stopping/resuming it. That is part of what set_initial_registers does. So what dwfl_attach_thread/dwfl_detach_thread really do is setting up the Dwfl_Thread so it can be queried/used. You are attached/detached on the process as a whole. Which is done with the dwfl_linux_proc_attach call. So basically I think what we want is an interface which you call pauzing the thread. Sorry for not having a clear vision of the perfect interface yet. Cheers, Mark
