linux-kernel - Re: [PATCH] MIPS: dec: Avoid la pseudo-instruction in delay slots

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.2.20.1609192323450.19345@eddie.linux-mips.org>
Date:   Mon, 19 Sep 2016 23:30:25 +0100 (BST)
From:   "Maciej W. Rozycki" <macro@...ux-mips.org>
To:     Paul Burton <paul.burton@...tec.com>
cc:     linux-mips@...ux-mips.org, Ralf Baechle <ralf@...ux-mips.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] MIPS: dec: Avoid la pseudo-instruction in delay slots

On Fri, 2 Sep 2016, Paul Burton wrote:

> When expanding the la or dla pseudo-instruction in a delay slot the GNU
> assembler will complain should the pseudo-instruction expand to multiple
> actual instructions, since only the first of them will be in the delay
> slot leading to the pseudo-instruction being only partially executed if
> the branch is taken. Use of PTR_LA in the dec int-handler.S leads to
> such warnings:
> 
>   arch/mips/dec/int-handler.S: Assembler messages:
>   arch/mips/dec/int-handler.S:149: Warning: macro instruction expanded into multiple instructions in a branch delay slot
>   arch/mips/dec/int-handler.S:198: Warning: macro instruction expanded into multiple instructions in a branch delay slot
> 
> Avoid this by placing nops in the delay slots of the affected branches,
> leading to the PTR_LA macros being placed after the branches & their
> delay slots. Although the nop isn't strictly needed, it's an
> insignificant cost & satisfies the assembler easily with more
> readable code than the possible alternative of manually expanding the
> la/dla pseudo-instructions & placing the appropriate first instruction
> into the delay slots.

 I take it it's a quest for a clean compilation with no warnings reported, 
as the message is otherwise harmless and correct code is produced here.

 Some of the systems affected are not necessarily fast (e.g. clocked at 
12MHz), so I wonder if we shouldn't just bite the bullet and expand the 
%hi/%lo pair here.  Even with R4k DECstations we only support `-msym32' 
compilation only, due to R4k errata, so it's not like the higher parts 
will ever be needed for address calculation.

 Alternatively we could have a `.set warn'/`.set nowarn' setting in GAS, 
previously discussed I believe, although it would take a bit to propagate.

  Maciej