corelow and threads question
Aleksandar Ristovski
aristovski@qnx.com
Fri Jun 5 18:55:00 GMT 2009
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: corelow.c.diff
Type: text/x-patch
Size: 1322 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/gdb/attachments/20090605/454091ab/attachment.bin>
More information about the Gdb
mailing list