RE: [PATCH v2] xtensa: initialize call_abi in xtensa_tdep

[Marc Gauthier <marc@cadence.com>]

Pedro Alves wrote:
> On 08/20/2015 02:37 PM, Max Filippov wrote:
> 
> > Actually it's as simple as unpacking a tarball to the source directory,
> > and we have it automated in the environments that build toolchains,
> > like the Buildroot or the crosstool-NG.
> >
> > The idea behind this is the following: Xtensa core is configurable, a
> lot
> > of its properties may be changed. Nobody even try to test all possible
> > combinations of configuration options and nobody really cares how many
> > Xtensa core configurations exist, people that generate Xtensa core
> > only care about their particular core. When they generate it they get
> > all the files that need to be changed in the toolchain, they apply them
> > and they get the toolchain for their particular core.
> 
> How about making the configuration generator tool output some data
> file that gdb would source?

As I understand it, a simple data file is problematic.  For example,
customers adding custom extensions to an Xtensa processor can describe
instruction operand encoding and decoding using arbitrary verilog
expressions.  Although typically simple, there is currently no constraint
on these expressions, so to fully support this, they get translated into
C code which GDB and other tools can use to assemble and disassemble
Xtensa instructions.

So the more natural "data file" to describe a custom processor is a shared
library or DLL.  This is what Cadence's Tensilica tools use.  However, in
the far past, upstreaming this approach was problematic given the various
projects' aversion to dynamic shared libraries, which aren't supported
on every host architecture (not all support a dlopen equivalent).

Might it be possible now to introduce use of a dynamic shared library?
If that works for GDB, my next question will be about binutils and gcc :-)

Thanks!
-Marc