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: [patch - gas] MIPS: fix problem with mips16 delay branchoptimization.


On Tue, 6 Sep 2005, Richard Sandiford wrote:

> But the code quoted above is adding the delay instruction (the one
> which originally gets added before the branch).  It shouldn't be
> used for the branch itself.  Note that the condition guarding it is:
> 
>     else if (mips_opts.mips16
>              && ! ip->use_extend
>              && *reloc_type != BFD_RELOC_MIPS16_JMP)
>       {
> 
> The point of reserving 6 bytes is that:
> 
>     (a) we can only use 2-byte instructions to a fill a delay slot
>     (b) branches are at most 4 bytes
>     (c) adding the branch shouldn't grow the frag by more than 4 bytes
> 
> So if we reserve 6 bytes, the branch should get placed in the same
> frag as the delay slot.  That's the idea anyway.

 IIRC, for code as is there is also a nasty interaction with DWARF-2 
information for these swaps and for extended branches it's hopeless as the 
result is "gdb" tends to place breakpoints in the middle, i.e. starting 
from byte #2 rather than the beginning, of the swapped branch.  Which 
breaks debugging badly -- you usually get SIGILL if you hit such a 
breakpoint or code actually executed may be different from what you'd 
expect.  For 2-byte branches at least it works somehow, but 
single-stepping at the source level is inexact, so execution may run away 
at times.

 Regrettably I have failed finding an easy way of updating DWARF-2 records 
at the time the swap happens.

  Maciej


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