Re: corelow and threads question

[Pedro Alves <pedro@codesourcery.com>]

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