Re: ptid from core section

[Aleksandar Ristovski <aristovski@qnx.com>]

Pedro Alves wrote:
> On Friday 05 June 2009 18:54:08, Aleksandar Ristovski wrote:
>> On nto, we are not using lwp field at all. We use thread id. 
>>   In nto, I override core_open to add thread private data 
>> once core_open has finished it's work. 
> 
> It's hard to guess without seeing the code, but, by overriding
> you mean: you have a function that replaces core_open itself, then
> that goes against the direction we want to go with corelow.c.  We
> want this file to work the same for both native and cross debugging,
> and overriding target_ops methods like that doesn't work well in
> that case.  :-(  That's why all new core support customising
> methods are done through gdbarch.
> 
> Hmmm,  I don't have the details on how you're storing or
> extracting that info, and if it is a different mechanism from
> when doing live debugging, but, there's a call to
> target_find_new_threads at the bottom of core_open:
> 
>   /* Now go through the target stack looking for threads since there
>      may be a thread_stratum target loaded on top of target core by
>      now.  The layer above should claim threads found in the BFD
>      sections.  */
>   target_find_new_threads ();
> 
> it may work for you to attach thread private data from
> within that callback.
> 
>> In summary: the motivation for this patch is to avoid having 
>> to patch corelow.c.
> 
> I understand that.  I was just asking/suggesting ( since the
> beggining of the thread, actually :-) ) that the nto overrides
> be included in the patch, so we'd understand if we're doing
> the right decisions, that's all.  I didn't know about that
> core_open override or the intention to add private data to
> threads.
> 
> On Friday 05 June 2009 18:54:08, Aleksandar Ristovski wrote:
>> Looking at core handling I think the whole thing is not 
>> clean. 
> 
> Cleaning up patches welcome.  We never have enough of those  :-)
> The other option I see, is to revamp, cleanup and and normalize
> how bfd exports core process or threads ids to GDB.  But, what,
> exactly, are you refering to as not clean?  corelow.c would
> be leaner and cleaner if we didn't have all those legacy targets
> using the deprecated mechanisms around in the tree, but we do.
> 
> Alternatively, I suppose it wouldn't be such a bad idea to
> officially declare that the lwp field of ptid is for kernel
> threads, and that the tid field is for user/thread library
> threads (thread_stratum targets) (which itself would mostly
> be useful to M:N configurations, where details of
> user thread registers are found somewhere in memory data
> structures).  Then, it would be clearer that the .reg sections
> map to kernel processes/lwps/threads.  This would mean that
> it wouldn't be such a stretch to make nto-procfs.c use the
> lwp field of ptids at all.
> 
>> I see your point, but I see no particular advantage  
>> of your approach - we moved the default code to corelow but 
>> now introduced check for gdbarch_..._p.
> 
> The advantage is that we only implement the default
> case *once* (core_gdbarch == NULL; not-NULL, but the arch
> doesn't implement the callbacks).
> 
>> But don't get me wrong - I am not against your approach - as 
>> long as I don't have to patch corelow in order to get gdb 
>> working for neutrino.
> 
> Ok, assuming it works, I'll check it in.
> 

Wait :-)

I have opened another thread in 
http://sourceware.org/ml/gdb/2009-06/msg00051.html

Maybe we don't need to customize it this way...

-- 
Aleksandar Ristovski
QNX Software Systems