RFC: MIPS: Workaround the "daddi" and "daddiu" errata

[Richard Sandiford]

"Maciej W. Rozycki" <macro@ds2.pg.gda.pl> writes:
>> Are you talking about the kernel refusing to run suspect binaries?
>> Or at least warning about them somehow?  If so, ELF offers far better
>> ways of detecting a "safe" binary than scanning all executable pages.
>
>  Yes, I think of a kind of a debugging facility that would do such 
> validation.
>
>  How can any ELF feature tell you there are no bad instructions in code in 
> a binary?  Any flags or special sections may at most show an effort was 
> done to deal with the problem.  This is useful, but not completely safe.  

That seems like a spurious argument to me.  If an ELF executable
identifies itself as VR5500 code, for example, how do you know you
know it's _really_ VR500 code, and there aren't any MIPS64 instructions
(or whatever) lurking in there as well?  You don't.  You just have to
trust whatever tool produced the executable (and fix that tool if does
the wrong thing).

>> >  Note that even if the address is invalid, code should work correctly --
>> > the address may be further offsetted later.  Or code may expect a bad
>> > address and deal with it somehow.  Or there may be a real bug in code --
>> > it should really get an exception then, instead of silently using a 
>> > different address.
>> 
>> But you seem to be missing my point.  Within GCC, I think all symbolic
>> constants are associated with pointers.  I don't know of any well-defined
>> way of creating a legitimate address by using an offset from an invalid
>> pointer.  And besides, in the normal run of things, an invalid constant
>> address could only be defined explicitly by the user, perhaps using a
>> linker script.
>
>  Well, something like:
>
> ((void (*)(void))0xffffffffbfc00000)();
>
> used to work for me to call the reset vector from Linux. ;-)  There's no
> need to resort to linker scripts to create arbitrary pointers -- the
> expression above could be changed to define e.g. an array.

Maciej, it feels like you're being deliberately awkwrd/obtuse here.

Of course ((void (*)(void))0xffffffffbfc00000) is a valid object.
It's also a valid pointer.  You still haven't shown any examples
of valid objects references based on an _invalid_ pointer.

>  The patch is tested with a snapshot of Linux 2.4.24 and appears to work
> fine -- I'm still debugging a problem with the fcntl syscall, but I think
> it's unrelated, being more a generic gcc 3.5.x compatibility problem, like
> a few I've already resolved.
>
>  What do you think?

Well, I spent a significant amount of time reviewing your previous
iterations on this patch and explaining what I thought should happen.
You don't seem to have made any real attempt to address my concerns.
So as far as I'm concerned, the patch is still unacceptable, for the
same reasons I gave earlier.  Feel free to try to convince someone
else to approve it instead though.

Richard