From: Max Filippov <jcmvbkbc@gmail.com>
To: Joel Brobecker <brobecker@adacore.com>
Cc: gdb-patches@sourceware.org, Maxim Grigoriev <maxim2405@gmail.com>,
Woody LaRue <larue@cadence.com>,
Marc Gauthier <marc@cadence.com>
Subject: Re: [RFC] Re: [PATCH v2] xtensa: initialize call_abi in xtensa_tdep
Date: Thu, 20 Aug 2015 13:44:00 -0000 [thread overview]
Message-ID: <CAMo8BfKkP+LFMEV_cwkzfWgoCxXJXDAvJTk6enVpHizx3HndjQ@mail.gmail.com> (raw)
In-Reply-To: <20150820131441.GG4571@adacore.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
next prev parent reply other threads:[~2015-08-20 13:44 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-20 12:53 Max Filippov
2015-08-20 13:07 ` Joel Brobecker
2015-08-20 13:14 ` [RFC] " Joel Brobecker
2015-08-20 13:44 ` Max Filippov [this message]
2015-08-20 13:37 ` Max Filippov
2015-08-20 14:13 ` Pedro Alves
2015-08-20 20:30 ` Marc Gauthier
2015-08-21 9:49 ` Pedro Alves
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAMo8BfKkP+LFMEV_cwkzfWgoCxXJXDAvJTk6enVpHizx3HndjQ@mail.gmail.com \
--to=jcmvbkbc@gmail.com \
--cc=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=larue@cadence.com \
--cc=marc@cadence.com \
--cc=maxim2405@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox