[PATCH] x86: reject architecture settings that are invalid to be set from the command line (v2)
Jan Beulich
JBeulich@novell.com
Thu Jun 10 16:06:00 GMT 2010
>>> On 10.06.10 at 17:55, "H.J. Lu" <hjl.tools@gmail.com> wrote:
> On Thu, Jun 10, 2010 at 8:13 AM, Jan Beulich <JBeulich@novell.com> wrote:
>> So far, options like -march=i8086 were accepted despite the assembler
>> subsequently choking on other consistency checks, leading to reasonably
>> cryptic error messages. This patch makes it so that impossible
>> architecure settings are neither accepted nor displayed (i.e. it is now
>> made sure that those settings can only be used via directives).
>>
>> gas/
>> 2010-06-10 Jan Beulich <jbeulich@novell.com>
>>
>> * config/tc-i386.c (md_parse_option): Ignore impossible processor
>> types.
>> (show_arch): New parameter 'check'.
>> (md_show_usage): Adjust calls to show_arch().
>>
>> --- a/gas/config/tc-i386.c
>> +++ b/gas/config/tc-i386.c
>> @@ -8166,6 +8166,11 @@ md_parse_option (int c, char *arg)
>> if (strcmp (arch, cpu_arch [j].name) == 0)
>> {
>> /* Processor. */
>> + if (! (strcmp (default_arch, "i386")
>> + ? cpu_arch[j].flags.bitfield.cpulm
>> + : cpu_arch[j].flags.bitfield.cpui386))
>> + continue;
>
>
> This is still wrong:
>
> [hjl@gnu-6 gas]$ ./as-new -march=i386 --32 x.s -o x.o
> Assembler messages:
> Fatal error: Invalid -march= option: `i386'
> [hjl@gnu-6 gas]$
>
> Please change it to
>
> if (!cpu_arch[j].flags.bitfield.cpui386)
> continue;
Didn't your original response mean only the other instance? I think
it is perfectly valid to require the options to be passed in sane
order (i.e. --32 first if you want to use -march=i386). I'm precisely
trying to reduce the number of cases where that (much less
meaningful imo) "xx-bit mode not supported" message appears.
Jan
More information about the Binutils
mailing list