On Mon, May 7, 2012 at 6:08 AM, Christian Bruel <christian.br...@st.com> wrote:
>
>
> 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.
I think http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49858 is
essentially this issue. It can probably be closed as "won't fix",
though I notice the spec file format is still documented in the user
manual.
Peter
>
> many thanks
>
> Christian
>
>
>>
