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

[Pedro Alves <palves@redhat.com>]

On 08/20/2015 09:30 PM, Marc Gauthier wrote:
> 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.

Does that mean you're replacing some src/opcodes/ files too, for disassembly?

> So the more natural "data file" to describe a custom processor is a shared
> library or DLL. 

Another option would be some Python API.

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

That's not really a problem.  Hosts that can't dlopen just don't
support all features.  From https://sourceware.org/gdb/wiki/Systems,
probably the only one would be MSDOS/djgpp.

E.g., GDB already supports a JIT debug info reader API, which loads a
shared library plugin into GDB.

 https://sourceware.org/gdb/onlinedocs/gdb/Writing-JIT-Debug-Info-Readers.html

Another example, GDB loads a libcc1.so library in order to invoke gcc, in
order to provide the new "compile" set of subcommands.

GCC is also extensible with plugins nowadays.  That's what the libcc1.so
library talks to -- a gcc plugin.

The binutils ld linker has a plugin interface, for loading the LTO plugin.

> Might it be possible now to introduce use of a dynamic shared library?

I think it'd be useful to see a couple representative diffs of pristine
FSF GDB vs a configured GDB, to get a better feel for what needs exposing.

> If that works for GDB, my next question will be about binutils and gcc :-)

Thanks,
Pedro Alves