Re: ptid from core section

[Pedro Alves <pedro at codesourcery dot com>]

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.

-- 
Pedro Alves