This is the mail archive of the gdb@sourceware.cygnus.com 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]

multi-arch (was Re: Makefile setting)



Stephane.Bihan@arccores.com wrote:
> >
> > > > the ARC supported implementation of gdb we are trying to achieve is
> > > > "extensible".
> > > > The register description is minimal in the sense that only the
basecase
> > > > registers are described in REGISTER_NAMES.
> > > > This description is updated (more registers are added) when we connect
to
> > the
> > > > simulator.
> > >
> > > Hmm, I'd suggest investigating the multi-arch framework.  It better
> > > handles things like an architecture suddenly deciding it needs to be
> > > changed.  A target can also forced multi-arch to re-select its
> > > architecture if needed.
> > >
> > > http://sourceware.cygnus.com/gdb/papers/multi-arch/
> > >
> > > For the register extensions, are they known by arcExtMap or are they
> > > obtained from the target?
> > >
> > They are extracted from the object file.
>
> Good, multi-arch should definitly help.  When a new object file is
> presented to GDB the multi-arch framework is asked to identify it and
> create an architecture for it.  arc-tdep.c can be set up to identify
> that information and set up things like the REGISTER_NAME
> (REGISTER_NAMES is being given the boot :-) for the relevant target.
>
> Just a few speed bumps to climb over before it starts to help.

That's a really good idea this multi-arch proposal!
Just a shame I didn't read the paper before.
I've implemented the REGISTER_NAMES initialisation in another way now.
And I haven't got too much time to change it before sending you the sources of
our ARC port.

Stephane.



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