Re: corelow and threads question

[Pedro Alves <pedro@codesourcery.com>]

On Tuesday 09 June 2009 17:10:09, Aleksandar Ristovski wrote:

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

Ok, then a new gdbarch callback would help you here?

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

If you do need this, then doesn't the first option I
gave fit?  That would be a new gdbarch_core_extra_thread_info,
for example.

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

I don't see that much different from having finer
grained gdbarch callbacks, which can have similar
interfaces to the target_ops methods, thus avoiding
issues with target stack/ops management (as I mentioned before,
think of a a single gdb binary that can debug both native linux
and cross nto: you'd have to undo your changes to core_ops
when you close your core).  Really, to get things done
right, I suggest you build your gdb on a linux host,
with --enable-targets=nto, and hack on your core support
until it can debug cores in that configuration.  :-)

-- 
Pedro Alves