This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
multi-arch (was Re: Makefile setting)
- To: Andrew Cagney <ac131313 at cygnus dot com>
- Subject: multi-arch (was Re: Makefile setting)
- From: Stephane dot Bihan at arccores dot com
- Date: Thu, 13 Apr 2000 10:15:18 +0100
- Cc: gdb at sourceware dot cygnus dot com,Stephane dot Bihan at arccores dot com
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.