On 05/07/2012 12:09 PM, Joseph S. Myers wrote:
> On Mon, 7 May 2012, Christian Bruel wrote:
>
>> Making the driver aware about all possible user defined options seems
>> unpredictable. Was there any justification on removing this
>> functionality or did I miss a point with the EXTRA_SPECS ?
>
> There are several motivations behind requiring all options to be defined
> in .opt files, including:
>
> * For multilibs to be selected based on the semantics of options, using
> values set in gcc_options structures by the same code as in cc1, rather
> than by textual matching attempting to replicate semantics, the driver
> needs to understand the semantics of options as similarly as possible to
> cc1, rather than treating any options purely textually.
>
> * Every option supported by the compiler should be listed in --help (and
> if the missing help information were all filled it, we could then make it
> a build failure to have an option without help information).
True but this removes the flexibility for a user or a BSP maintainer to
define new options, e.g to the linker not the compiler, without access
to the compiler sources using a --spec= file..
>
> * Structured option information enables consistency in how options are
> processed and errors given for unknown options or arguments.
>
> * It would be useful for the compiler to be able to export structured
> information about all its options for use by tools such as IDEs.
If the option is only supported by a BSP, and not by the compiler, I
don't see how the compiler could report it since it doesn't depend on
static information known at build time.
A direction would be to add this information in the user spec rules
*ldruntime:
+ %{foo: -lfoo} %{help: "describe foo "}
I'm not aware about such machinery. maybe an idea of improvement ?
>
> There is certainly room for more extensibility in option handling -
> ideally there would not be one big enum with OPT_* values for all options
> and one header with all the macros and structures, but instead front-end
> and back-end options would use some form of separate namespace for their
> options so the language- and target-independent compiler doesn't see the
> options for other parts of the compiler; that fits into the modularity
> theme that ideally it would be possible to build multiple front ends and
> back ends into the compiler at once, or to build front ends and back ends
> separately from the compiler. But defining options through use in specs
> wouldn't be part of that; rather more structured information about each
> option would need to be provided somehow by a separately built front end
> or back end.
>
> If you want -m options to select arbitrary board support packages (and the
> existing ability to use -T to name a linker script isn't sufficient), then
> a -mbsp= option, whose argument is not interpreted by GCC but may be
> processed by whatever specs you are adding after GCC is installed, would
> seem better than lots of separate -m options.
I don't like this -mbsp= alternative a lot, seems confusing, not
elegant, and not general for other uses (could be a runtime
customization, not bsp).
What about delimiters, something like --start-specs ... --end-specs ?
>
> As for options in specs included with GCC: they are all meant to be in the
> .opt files. I went through all the specs in all the config/ headers in
> GCC and added options found to .opt files before disallowing options not
> included in .opt files, but as there are about 500 such headers it's quite
> possible I missed some specs-defined options in the process.
yes it looks ok for the GCC specs, the problem is for the user spec
files. This is a new legacy issue, I thought it was worth to either
report it, and see if this need/can be fixed.
many thanks
Christian
>
