public inbox for
 help / color / mirror / Atom feed
From: Max Filippov <>
To: "" <>
Cc: "" <>,
		"" <>,
	Le-Chun Wu <>
Subject: Re: [RFC 2/5] gcc: xtensa: make configuration dynamic
Date: Thu, 25 May 2017 20:57:00 -0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Thu, May 25, 2017 at 11:24 AM,
<> wrote:
> On Mon, May 22, 2017 at 2:09 PM, Max Filippov <> wrote:
>> Now that XCHAL_* macros don't have to be preprocessor constants add
>> include/xtensa-dynconfig.h that defines them as fields of a structure
>> returned from the xtensa_get_config function.
>> Define that structure and fill it with default parameter values
>> specified in the include/xtensa-config.h.
>> Define reusable function xtensa_load_config that tries to load
>> configuration and return an address of an exported object from it.
>> Define the function xtensa_get_config that uses xtensa_load_config to
>> get structure xtensa_config, either dynamically configured or the
>> default.
>> 2017-05-22  Max Filippov  <>
>> gcc/
>>         * (PLUGIN_HEADERS): Add include/xtensa-dynconfig.h.
>>         * config.gcc (xtensa*-*-*): Add xtensa-config.o to extra_objs.
>>         * gcc/config/xtensa/t-xtensa (xtensa-config.o): New rule.
>>         * gcc/config/xtensa/xtensa-config.c: New file.
>>         * gcc/config/xtensa/xtensa.h (xtensa-config.h): Replace #include
>>         with xtensa-dynconfig.h
>>          XCHAL_HAVE_FP_POSTINC): Drop definitions.
> This almost certainly should go through the normal gcc plugin
> mechanism instead of the hand-rolled one you have here.
> If there is a reason it can't (and I'm not sufficiently familiar with
> the issues here), then you need to ensure that the various protections
> enforced by the normal plugin mechanism is used--and someone more
> knowledgeable than me needs to review it.

(adding Le-Chun Wu, current reviewer of the plugin code)

I tried to use plugins initially, but the following considerations made me
lean towards this implementation:
- we don't actually need any of the functionality available to gcc plugins,
  we only need to provide a data structure that the compiler knows how
  to use;
- using environment variable makes configuration transparent for gcc, all
  binutils and gdb, whereas using gcc plugin would require changing gcc
  invocation command line, which is not always possible;
- this implementation is shared between gcc and binutils. OTOH using
  plugin with gcc suggests using plugin with binutils, where it's substantially
  different and not universally supported across different binutils components
  (particularly neither assembler nor objdump have any support for it);
- gcc does not support plugins when built for windows host using MinGW;

Does the above justify this implementation? If no, are there any suggestions
how the above points may be addressed?

> Please note that by using a plugin mechanism, there are licensing
> issues that come into play, that are different from the usual
> licensing issues. I would be absolutely sure that you all are OK with
> how the runtime exception applies to this new situation.

All code used for building the configuration shared object is either GPL
(part of binutils) or MIT (xtensa configuration overlay), so it should be ok?

-- Max

  reply	other threads:[~2017-05-25 20:31 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-22 21:09 [RFC 0/5] xtensa: support dynamic configuration Max Filippov
2017-05-22 21:09 ` [RFC 3/5] gcc: xtensa: support dynconfig on windows Max Filippov
2017-05-22 21:09 ` [RFC 5/5] libgcc: xtensa: use built-in configuration Max Filippov
2017-05-22 21:09 ` [RFC 4/5] gcc: xtensa: add __XCHAL_* builtins Max Filippov
2017-05-22 21:09 ` [RFC 2/5] gcc: xtensa: make configuration dynamic Max Filippov
2017-05-25 18:25   ` augustine.sterling
2017-05-25 20:57     ` Max Filippov [this message]
2017-05-26 15:04       ` Ian Lance Taylor via gcc-patches
2017-05-26 18:48         ` Max Filippov
2017-05-22 21:31 ` [RFC 1/5] gcc: xtensa: allow XCHAL_* macros to be non-constant Max Filippov
2017-05-22 21:49   ` augustine.sterling
2017-05-23  2:19     ` Max Filippov
2017-05-25 18:24   ` augustine.sterling
2017-06-14 17:23     ` Max Filippov

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \

* 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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).