This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gcc doesn't accept specs options anymore



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


> 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]