Re: corelow and threads question

[Aleksandar Ristovski <aristovski@qnx.com>]

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