Hello,

Since: 
http://sourceware.org/ml/gdb-patches/2009-06/msg00101.html 
diverged from original intention, I would like to ask a 
question regarding core_ops and possible solution to my problem.

Right now, we are treating core_ops somewhat specially since 
we add threads before calling target_find_new_threads in 
core_open; but why don't we let target_find_new_threads add 
the threads instead of adding them in core_open?

Wouldn't that actually be the right solution?

(attached is diff for corelow.c that illustrates what I am 
talking about).



With corelow.c patched as proposed, on Neutrino I could do this:

For NTO, I "hijack" core_ops:
static void
init_nto_core_ops ()
{
   struct target_ops *core_ops;

   core_ops = find_core_target ();
   gdb_assert (core_ops && core_ops->to_shortname != NULL
               && !!"core_ops must be initialized first!");
   original_core_ops = *core_ops;
   core_ops->to_extra_thread_info = 
nto_target_extra_thread_info;
   core_ops->to_open = nto_core_open;
   core_ops->to_xfer_partial = nto_core_xfer_partial;
   core_ops->to_pid_to_str = nto_pid_to_str;
}

I can provide to_find_new_threads there:

static void
nto_find_new_threads_in_core (void)
{
   if (core_bfd)
     bfd_map_over_sections (core_bfd, 
nto_core_add_thread_private_data, NULL);
}

where I add_thread and also add thread private data. All 
works well.


Thoughts?

-- 
Aleksandar Ristovski
QNX Software Systems