This is the mail archive of the
mailing list for the binutils project.
Re: [MIPS] avoiding certain instruction in delay slots
- From: Sven Anderson <sven at anderson dot de>
- To: Richard Sandiford <rdsandiford at googlemail dot com>
- Cc: binutils at sourceware dot org
- Date: Tue, 4 Feb 2014 00:52:07 +0100
- Subject: Re: [MIPS] avoiding certain instruction in delay slots
- Authentication-results: sourceware.org; auth=none
- References: <52EF785C dot 7010509 at anderson dot de> <87fvo0dz1g dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com> <52EFBD4D dot 1040505 at anderson dot de> <878utsdtjw dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com>
Am 03.02.2014 um 17:56 schrieb Richard Sandiford <email@example.com>:
> Sven Anderson <firstname.lastname@example.org> writes:
>> On 03.02.2014 15:57, Richard Sandiford wrote:
>>> (In answer to your question, the assembler really does need to honour
>>> ".set noreorder"; we can never insert fixup nops while that's in effect.)
>> Is it not allowed "by contract" or is it technically not possible?
> By contract. ".set noreorder" means we must assemble the code exactly
> as written, with no extra instructions or swaps. (This is of course
> what most assemblers do by default.)
>> So the only thing I can do is to bail-out with an error, if there is a bad
>> instruction found in a delay-slot in a noreorder section (in manually
>> written assembly)?
Well, I have to break the contract anyway, so I'd be happy if my tools would support me with it. ;-) For example uClibc-0.9.32/libc/string/mips/memcpy.S contains problematic code. Instead of editing all the files by hand, it would be great to have a tool that automatically changes the instruction order, no matter if it is in a noreorder section. I understand the reluctance to support this in the assembler itself, but isn't an option to work around a buggy CPU a case for an exception, that breaks the rules with a "use-at-your-own-risk"-switch?
If I'd like to implement this at least for my personal gas edition, how can I implement the reordering? Is there similar code I could look at?
>>> If this particular errata applies specifically to delay slots though,
>>> you'd need to handle it differently from -mfix-24k. You'd need to teach
>>> both GCC and GAS about the restrictions. In the GCC case this would be
>>> by setting the "can_delay" attribute to "no" for the problem cases,
>>> while for GAS it would be making can_swap_branch_p return false.
>> In the meantime I found some sources of the patched toolchain in the net
>> which contained a patch for gcc-3.4.4. It does exactly what you propose
>> here (although there was no can_swap_branch_p() at that time). However,
>> if I understand it correctly, both things make sure that no bad code is
>> constructed, but what for the case of manually written assembly that
>> already filled the delay slots in a reorder section? Could I correct
>> that? I just want to guarantee that 100% of the executables are free of
>> the errata bad-code, and better fail with an error as a last resort.
> Yeah, the error would need separate code, although obviously it'd be nice
> for the error test and can_swap_branch_p to share a common subroutine
> that checks for problem instructions. append_insn is probably the best
> place to test for the error.
I see, thanks for the advice.
> BTW, not sure whether you were thinking of sending in a patch, but if you do,
> it'd need to be covered by an FSF copyright assignment. That means you'd
> probably need to write the patch from scratch rather than base it on an
> existing one from the internet.
Well, these patches barely have enough originality to be covered by copyright, but anyway I would rewrite them on my own. The question is more, if this errata workaround is of general interest, since it doesn't seem to be public and I have no idea which other SoC might have the same bug. Is it usual that errata are confidential? If yes, how are they usually handled by gcc/gas?