Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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


  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