x86/arm32: MacroAssembler::load64 does not consider whether its address overlaps the output register
Categories
(Core :: JavaScript Engine: JIT, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox95 | --- | fixed |
People
(Reporter: lth, Assigned: lth)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
load64 on arm32 and x86 may overlap the 64-bit output register with registers in the address expression, but does not consider this possibility. (There are two variants, aligned and unaligned load, but the latter delegates to the former.) Thus the pointer may be clobbered by the first word load and the second word load will go wrong. I just ran into this with some unshipped code.
This looks like a potential mess to fix - for Address it's not so hard, we can reverse the loads if we need to. For BaseIndex, the address has two registers and may both overlap the output register.
The problem can sometimes be fixed higher up in the stack by not reusing an input.
|
Assignee | |
Comment 1•3 years ago
|
||
|
|
Assignee | |
Comment 2•3 years ago
|
||
This is not currently an actual problem. I have vetted every use of load64(), and there is only one latent problem in the code generator: WasmLoadTls has an unconditional useRegisterAtStart(tlsPtr) and here the pointer register will potentially overlap with the output register when a 64-bit value is loaded on a 32-bit system. But that situation does not arise, because the only such 64-bit value is the bounds check limit and on 32-bit systems that is always a 32-bit value and we never load more than the low word of it. So the only real bug is in a patch stack that is still under development.
It doesn't look like I'm able to open this bug up. :dveditz, can you take care of that? Thanks.
|
||
Updated•3 years ago
|
|
||
Updated•3 years ago
|
Pushed by lhansen@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/052b313e7c71 Make load64() resilient on 32-bit. r=nbp
|
||
Comment 4•3 years ago
|
||
| bugherder | ||
Description
•