This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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
	li	$5, 2f - 0b
	addiu	$4, $pc, 0b - 1b
	jal	bar			# do something about foo
	.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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]