[PATCH] [ARC] Fix handling of cpu=... disassembler option value

[Pedro Alves]

On 06/16/2017 12:44 PM, Anton Kolesov wrote:

>> Couldn't this use disassembler_options_cmp /
>> FOR_EACH_DISASSEMBLER_OPTION?
>> See e.g. ppc-dis.c:ppc_parse_cpu for example.
> 
> FOR_EACH_DISASSEMBLER_OPTION advances pointer to the beginning of next option,
> but it doesn't create a new string with \0 at the end. So, for example, this
> code:
> 
>   const char* option;
>   FOR_EACH_DISASSEMBLER_OPTION (option, "fpuda,fpud,fpus")
>     {
>       printf ("option: %s\n", option);
>     }
> 
> will print:
> 
>   option: fpuda,fpud,fpus
>   option: fpud,fpus
>   option: fpus
> 
> As a result this macro can be used to improve existing code in arc-dis.c,
> however it doesn't address the issue that this particular patch is trying to
> fix. 

Hmm, the description you originally send only talked about parsing the
option value incorrectly.  If you change arc-dis.c:parse_cpu_option
to use disassembler_options_cmp for comparing options, then I think
it should fix the original issue you described?  Guess the issue then would
be that disassembler_options_cmp is case sensitive.  I wonder whether
architectures really want to be different here..

Oh well.

IMO, it's arguable whether to consider printing the whole string starting at
what failed to be parsed as a bug.  I find it fine.  ppc-dis.c:powerpc_init_dialect
also prints the whole string starting from the invalid option, AFAICS.
(And GDB does that in many other cases too.)

Actually I find it a bug that this code even prints to stderr directly
in the first place.  That'll be the wrong thing to do when this code
is being called by GDB -- a gdb Python script can disassemble with output
redirected to a string, for example.

Thanks,
Pedro Alves