Markos Chandras <Markos.Chandras@xxxxxxxxxx> writes: > On 01/19/2015 07:25 PM, Maciej W. Rozycki wrote: > > On Mon, 19 Jan 2015, Maciej W. Rozycki wrote: > > > >>> sorry i might be missing something but why do you think this is an > >>> important bug fix that should go into 3.19? the way i read the code it > >>> seems that it can't go wrong at the moment. > >> > >> We shouldn't be using trapping instructions for address calculation. > >> These macros have been wrong since the beginning, the MSA instructions > >> they correspond to do not trigger an exception on an integer overflow > in > >> address calculation (none of the MIPS instruction does). > > > > And BTW, it is a bug in GAS too, that it does not accept ADDI for R6 -- > > it should treat the instruction as a macro and expand it to an > equivalent > > LI + ADD sequence (using $at or `rd', if available, as a temporary to > > store the immediate). Similarly to how microMIPS DADDI is handled for > > example (where the hardware instruction has an unusually limited range > of > > the immediate argument, however GAS accepts any 16-bit). I suspect this is a discussion best moved to binutils but I have differing opinions on the value of macros that simply hide the true code that will be generated. I agree with everything relating to the kernel patch, there is definitely a 64-bit addressing issue here. Thanks, Matthew
