This is the mail archive of the binutils@sourceware.org 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
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


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