corelow and threads question
Aleksandar Ristovski
aristovski@qnx.com
Tue Jun 9 16:10:00 GMT 2009
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
More information about the Gdb
mailing list