This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: corelow and threads question
Daniel Jacobowitz wrote:
On Fri, Jun 05, 2009 at 02:54:54PM -0400, Aleksandar Ristovski wrote:
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?
I think the version you have now will cause "info threads" to
duplicate threads every time you type it. The current version
reflects that threads are only added when the target is opened.
I missed to add to the example code that I set
core_ops->to_find_new_threads = nto_find_new_threads_in_core;
I tested on neutrino, it doesn't duplicate threads: notice I
removed snippet with bfd_map_over_sections from core_open
and moved it into new core_find_new_threads which represents
default to_find_new_threads; then I override it in nto-tdep.c
That said, I think either way is fine - but you'll have to detect
already-added threads.
I don't think there would be any already added threads? If
core_open doesn't add them, but defers that to
target_find_new_threads, I believe (and my test with
neutrino shows that) we wouldn't have any threads at
"find_new_threads" time.
However, I am still unclear on whether overriding core_ops
the way I implemented it is the right way, or should I
somewhere do a "push_target (&nto_core_ops)"?
--
Aleksandar Ristovski
QNX Software Systems