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