Re: corelow and threads question

[Aleksandar Ristovski <aristovski@qnx.com>]

Hello Pedro,

Thanks for your comments.

Pedro Alves wrote:
> On Friday 05 June 2009 20:40:23, Aleksandar Ristovski wrote:
> 
>> +static LONGEST
>> +nto_core_xfer_partial (struct target_ops *ops, enum target_object object,
>> +                      const char *annex, gdb_byte *readbuf,
>> +                      const gdb_byte *writebuf, ULONGEST offset, LONGEST len)
>> +{
>> +  if (object == TARGET_OBJECT_AUXV
>> +      && readbuf)
>> +    {
...
> 
> You don't really need this.  Fix bfd/elf.c to grok the note, and export
> a .auxv section, just like corelow.c expects, and other archs do.

I agree, however, my problem is, we do not really dump auxv 
in a note, I have to retrieve auxv from initial stack; I 
only read status from the note (and from status initial 
stack), then have to read target memory to fetch auxv.

> 
>> +  core_ops->to_extra_thread_info = nto_target_extra_thread_info;
> 
> Looks like one of two things would be possible here:
>  - a gdbarch callback so that cores can customize this, move the
>    needed code into a nto-tdep.c file, and register the callback.
>  - come up with new fake bfd sections like e.g., ".thrextrainfo/TID"
>    (named similarly to to .reg/TID), whose contents would simply be the
>    string GDB should display, in target_extra_thread_info.  Implement support
>    for that in bfd and corelow.c.

The main purpose of fetching extra thread info is to fetch 
thread statuses.

> 
>> +  core_ops->to_xfer_partial = nto_core_xfer_partial;
> 
> This isn't needed, as explained.
> 
>> +  core_ops->to_pid_to_str = nto_pid_to_str;
> 
> There's already a gdbarch callback  for this.

Ok, thanks.

> 
>> +  core_ops->to_find_new_threads = nto_find_new_threads_in_core;
> 
> Then you'd not have a need for this.  Do any extra needed processing
> lazilly in to_extra_thread_info if you must.
> 

But I do not have my to_extra_thread_info active?

I think this is going back to my initial question (pardon my 
ignorance): how do I "install" my to_extra_thread_info? I 
don't see a clean way of pushing my core_ops on top of 
default ones (and I thought that would be a clean way).

I think letting architecture push its customization on top 
of default provided _ops would be very useful. In the 
core_ops example, maybe we could have arch. callback for 
that, and have the callback be called from core_open just 
after core_open pushes core_ops?  That would definitely 
solve all the problems I have in a generic way.


Thanks,

-- 
Aleksandar Ristovski
QNX Software Systems