This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH v2] xtensa: initialize call_abi in xtensa_tdep
- From: Pedro Alves <palves at redhat dot com>
- To: Marc Gauthier <marc at cadence dot com>, Max Filippov <jcmvbkbc at gmail dot com>, Joel Brobecker <brobecker at adacore dot com>
- Cc: "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>, Maxim Grigoriev <maxim2405 at gmail dot com>, Woody LaRue <larue at cadence dot com>
- Date: Fri, 21 Aug 2015 10:49:33 +0100
- Subject: Re: [PATCH v2] xtensa: initialize call_abi in xtensa_tdep
- Authentication-results: sourceware.org; auth=none
- References: <1440075160-13310-1-git-send-email-jcmvbkbc at gmail dot com> <20150820130736 dot GF4571 at adacore dot com> <CAMo8BfK3AKap6eSV0j4hL1MypgH=D81jK1DAMEapKsUSOB3Jfw at mail dot gmail dot com> <55D5E088 dot 3050807 at redhat dot com> <SN1PR0701MB185363DCD63A32E87803BEDAC3660 at SN1PR0701MB1853 dot namprd07 dot prod dot outlook dot 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