This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: corelow and threads question


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)
> + ? ?{
> + ? ? ?struct auxv_buf auxv_buf;
> +
> + ? ? ?auxv_buf.len = len;
> + ? ? ?auxv_buf.len_read = 0;
> + ? ? ?auxv_buf.readbuf = readbuf;
> + ? ? ?
> + ? ? ?if (offset > 0)
> +???????return 0;
> +
> + ? ? ?bfd_map_over_sections (core_bfd, nto_core_read_auxv_from_note, &auxv_buf);
> + ? ? ?if (auxv_buf.len_read > 0)
> +???????return auxv_buf.len_read;
> + ? ?}
> +
> + ?/* In any other case, try default code. ?*/
> + ?return original_core_ops.to_xfer_partial (ops, object, annex, readbuf,
> +??????????????????????????????????????? ? ?writebuf, offset, len);
> +} 

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.

> + ?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.

> + ?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.

> + ?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.

-- 
Pedro Alves


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]