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

[Max Filippov <jcmvbkbc at gmail dot com>]

On Thu, Aug 20, 2015 at 4:07 PM, Joel Brobecker <brobecker@adacore.com> wrote:
> On Thu, Aug 20, 2015 at 03:52:40PM +0300, Max Filippov wrote:
>> Use XSHAL_ABI value provided by xtensa-config.h to correctly initialize
>> xtensa_tdep.call_abi
>> This fixes calls to functions from GDB that otherwise fail with the
>> following assertion in call0 configuration:
>>
>>   gdb/regcache.c:602: internal-error: regcache_raw_read: Assertion
>>   `regnum >= 0 && regnum < regcache->descr->nr_raw_registers' failed.
>>
>> gdb/
>>       * xtensa-tdep.h (XTENSA_GDBARCH_TDEP_INSTANTIATE): Initialize
>>       call_abi using XSHAL_ABI macro.
>
> I think you missed or ignored one comment about the fact that
> the code I am seeing in current xtensa-tdep.h is not what your patch
> says.

Sorry, I'm not sure what you mean. I've changed call_abi initialization
in the macro XTENSA_GDBARCH_TDEP_INSTANTIATE in file
gdb/xtensa-tdep.h from 'call_abi = 0' to 'call_abi = (XSHAL_ABI == ...',
which I wrote to the changelog.

> So it seems to me you are sending a patch that doesn't seem
> to be applying to master.

You're right, I haven't rebased v2 to the current master and now it indeed
does not apply. I'll send fixed v3.

> I would also be beneficial to explore what I was trying to explain
> regarding the fact that determining the proper ABI should be done
> on the fly, rather than hardcoded. This is particularly true with
> the fact that changing the hardcoded values involves adapting
> the contents of a file, which is not user-friendly, and nearly
> impossible for anyone but a knowledgeable GDB contributor.

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.

-- 
Thanks.
-- Max