Ditto. Jim, are you reading from some documentation about this option processing that I couldn't find ? I've spend hours and hours to try to deduce the option processing rules from debugging various parts of the gcc driver, with no success.
I doubt that this stuff is well documented. There are some comments at the top of gcc.c that give basic info on option processing, and there are comments a bit farther down that explain how spec strings work.
Actual argument handling happens inside do_spec* as a side-effect of reading the spec strings. If an option matches a spec string, it is processed. If it doesn't, it is ignored. This happens in handle_braces, where it calls process_marked_switches. There is also some earlier argument parsing, which does stuff like handle arguments with options, see translate_options. There is also some code to check for options that aren't handled by any spec string, see validate_all_switches.
The rules for which options go to which programs were developed by trial and error, and most of the errors happened long ago. These rules are now encoded in the various spec strings. So cc1_options has %{d*}, %{f*}, and %{m*} which implies that -d*, -f*, and -m* are all reserved for compiler binaries. cpp_unique_options contains %{i*} which implies that all -i* options are reserved for the preprocessor. LINK_COMMAND_SPEC contains %{e*}, %{u*}, %{L*}, and %{T*} which implies that -e*, -u*, -L*, and -T* are all reserved for the linker. Etc.
If you want to use an option that differs from the normal naming scheme, then you need to examine all spec strings in the gcc driver and all target files to make sure that there is no conflict. And this isn't foolproof, because there could be conflicts with systems not supported yet, or options on existing targets that aren't explicitly handled by specs. It is easier and safer to just stick to the normal naming scheme, -d* for debugging dumps, -f* for front end and optimizer options, -m* for target dependent options, etc.
If you do need to extend the system, then it is best to use option names similar to existing ones. For instance, -z and -Z are assumed to be linker options, so if you need a new linker option then something like -zthis or -Zthat might be a good choice. This trick is used by darwin which supports a slew of -Z* options that look mostly like special linker options. This trick doesn't work as well with a language front end though. Darwin doesn't have to worry about conflicting with other targets. You do. So it is best if a language front end is conservative about option choices.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
