Re: ARM: Add literal pool blocking to position critical code. (issue 10451037)

[m.m.ca...@googlemail.com]

Ping. Anybody have time to look at this? It should bring stability
improvements.

Thanks.


http://codereview.chromium.org/10451037/

[Daniel Clifford]

Hi Martyn,

Sorry, this one slipped through the cracks. I'll make sure it gets looked at.

Danno

[da...@chromium.org]

Sven, can you please take a look? Thanks, Danno

http://codereview.chromium.org/10451037/

[sven...@chromium.org]

LGTM, I'll land this CL. 2 remarks:

* Finding the places where blocking is necessary is tricky, can we perhaps
find a mechanical way to detect these?

* Our ToT is currently in a pitiful state, but it seems that this CL
doesn't
make it any worse. ;-)

http://codereview.chromium.org/10451037/

[M Capewell]

On Jun 12, 6:26 pm, svenpa...@chromium.org wrote:
> LGTM, I'll land this CL. 2 remarks:
>
>    * Finding the places where blocking is necessary is tricky, can we perhaps
> find a mechanical way to detect these?

Agreed, they are difficult to find. The method we're using is a hack
that generates literal pools very frequently, then we debug each
failure in the test suite. I guess when we clear these failures, we
should add this high-frequency literal pool hack as a shell feature,
to prevent regressions.

[Rodolph Perfetta]

Hi Sven,

>  * Finding the places where blocking is necessary is tricky, can we perhaps
> find a mechanical way to detect these?

We considered the following options but would like some feedback
before we go further:

1 ) Emit literal pools more frequently, this is what we did but it
completely overlooks code sequences where there is no literal pool
waiting to be emitted.
2 ) Make the assembler emit a nop between every instruction when there
is no constant pool block. That should catch most mistakes as any
offset computation which is not protected will be wrong but it may get
tricky to pinpoint the exact place where things went wrong.
3 ) a variant of 2 ) where two instructions are inserted between every
instructions: b 2 instructions ahead; brkpt (or swi). This would in
some cases caught the error sooner in the execution stream, but is it
worth the effort?
4 ) a variant of 2 ) where the nop inserted between instruction is
only used for this purpose, then the simulator is updated to check the
instruction executed before the nop was the one above (we should never
jump straight to these nops). This obviously only work in the
simulator.

Then we would need to decide if this is enabled by default for debug
or if this is activated by a flag.

What do you think?

Regards,
Rodolph.