This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATC] MIPS16/GAS: Permit branch swapping with PC-relative insns
On Thu, 11 Aug 2011, Richard Sandiford wrote:
> > Hmm, I have troubles buying that -- that can be true about any address
> > calculation that gets swapped into a branch delay slot. And about the
> > only use of such calculation, requiring the resulting address to point to
> > the instruction doing it, is to patch it with something else in
> > self-modifying code, which sounds useless, but let it be that I may be
> > overlooking something here.
> >
> > What I do not overlook, and neither you do, is that such code requires a
> > noreorder block, or otherwise GAS is essentially *by definition* free to
> > shuffle code around, transform instructions, add NOPs and do all kinds of
> > weird stuff, so I fail to see why we should be refraining from making this
> > particular change.
>
> So you're agreeing with me that it is very unlikely that such code will
> ever be written. And yet you insist on changing the behaviour for it
> (and for nothing else) anyway.
I only wrote that such code shouldn't depend on exact instruction
scheduling. It's perfectly OK to write e.g. such a piece:
.ent foo
foo:
0:
[...]
li $5, 2f - 0b
1:
addiu $4, $pc, 0b - 1b
jal bar # do something about foo
[...]
2:
.end foo
That'll work the same if ADDIU and JAL are swapped.
Someone has put the condition in though for some reason and if that
reason was legitimate, then I agree the condition should stay (though the
reason better was stated in the associated comment, which it is not now).
If the reason was misunderstanding how MIPS16 PC-relative instructions
work, then the condition should be removed.
I gather you don't know what the case is though and given the current
approach is certainly safe I won't insist anymore.
> > Have you got any historical records that back up your position and
> > explain why this statement has originally been placed in? Otherwise I'd
> > just expect a misunderstanding of how unusually the addition is calculated
> > -- which would be unsurprising to me, as I've seen similar mistakes
> > elsewhere, e.g. up until recently (I believe) QEMU used to get the result
> > of these instructions in delay slots wrong -- hopefully this piece of GAS
> > code is not a workaround for that!
>
> I think this code existed long before QEMU.
I just gave it as an example of how people easily miss subtle details.
I would have expected this code to date back to late 1990s.
Maciej