Re: [PATCH] microMIPS support

[Joel Brobecker <brobecker@adacore.com>]

I could only scan the patch briefly for today, but noticed something
that caught my attention:

> +/* For backwards compatibility we default to MIPS16.  This flag is
> +   overridden as soon as unambiguous ELF file flags tell us the
> +   compressed ISA encoding used.  */
> +static const char mips_compression_mips16[] = "mips16";
> +static const char mips_compression_micromips[] = "micromips";
> +static const char *mips_compression_strings[] = {
> +  mips_compression_mips16,
> +  mips_compression_micromips,
> +  NULL
> +};

We usually provide this sort of feature a little differently: Instead
of 2 values that are adjusted automatically by the debugger, we provide
3 values: auto, mips16, and micromips. If auto, then the debugger has
to guess, possibly defaulting to mips16 if guessing did not work.
But if the user sets the setting to either of the non-auto values,
then the setting should be honored, even if the user is wrong.

This is usually implemented using two variables: One representing
the setting, and one representing the actual value.

This brings me to the next question: Could this be an objfile-specific
setting? In other words, is it possible to that the same executable
might have one objfile using micromips while another might still be
using mips16? (this might be the stupidest question of the week...).
If not, I still believe that this is at least an inferior-specific
property. With multi-inferior debugging being possible, I can see
how one debugs two programs using a different setting. In that case,
you need to store that information in the inferior private data
(I do that in ada-tasks, IIRC, for storing the layout of some data
structures).

(oops, style issue as well, the opening curly bracket should be
at the start of the next line - we've seen a lot of your style too,
but I think it should be fixed)

-- 
Joel