corelow and threads question
Pedro Alves
pedro@codesourcery.com
Sat Jun 6 00:27:00 GMT 2009
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
More information about the Gdb
mailing list