This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC] Re: [PATCH v2] xtensa: initialize call_abi in xtensa_tdep
- From: Max Filippov <jcmvbkbc at gmail dot com>
- To: Joel Brobecker <brobecker at adacore dot com>
- Cc: gdb-patches at sourceware dot org, Maxim Grigoriev <maxim2405 at gmail dot com>, Woody LaRue <larue at cadence dot com>, Marc Gauthier <marc at cadence dot com>
- Date: Thu, 20 Aug 2015 16:44:21 +0300
- Subject: Re: [RFC] 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> <20150820131441 dot GG4571 at adacore dot com>
On Thu, Aug 20, 2015 at 4:14 PM, Joel Brobecker <brobecker@adacore.com> wrote:
>> 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. So it seems to me you are sending a patch that doesn't seem
>> to be applying to master.
>>
>> 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.
>
> You answered in the other email:
> | I agree with that, but currently we can't distinguish executables with
> | different call ABI.
>
> Odd; that means that the linker would not reject the link of
> objects that use different calling conventions? Wow, better be
> careful!
Yes, but as long as the calling convention is fixed for the toolchain
this is not a problem.
> In any case, I think what should really be done, if it has to be
> hard-set in the debugger, is use a configure command-line option.
> Or use a GDB setting "set xtensa call-abi [...]".
This only increases the number of moving parts: where previously
only a set of files had to be replaced we'd now have to change a
set of files plus give some configuration options. It isn't needed for
our usecase: the particular build of gdb is meant to be used with
matching build of the compiler, linker and the hardware.
> In the meantime, I have no strong objection to this code going in
> on the grounds that it doesn't really make things all that worse.
> But given that this is going against what I would recommend, give it
> another week so that other Maintainers have a chance to comment
> as well if they disagree with letting this in.
--
Thanks.
-- Max