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] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.20.1609210301430.19345@eddie.linux-mips.org>
Date:   Mon, 3 Oct 2016 01:21:41 +0100 (BST)
From:   "Maciej W. Rozycki" <macro@...ux-mips.org>
To:     Ralf Baechle <ralf@...ux-mips.org>
cc:     Paul Burton <paul.burton@...tec.com>, linux-mips@...ux-mips.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] MIPS: dec: Avoid la pseudo-instruction in delay slots

On Tue, 20 Sep 2016, Ralf Baechle wrote:

> >  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.
> 
> Yeah, I'm already looking into the other direction whenever this warning
> pops up - and it does so often.  I've even pondered submitting something
> like -Werror for gas ;-)

 Well, the GCC driver already handles it and catches warnings from GAS if 
requested, doesn't it?

> It's not very elegant but you could just open code everything, see below
> patch.  Compiles but not runtime tested due to lack of hardware.

 That's what I noted above and as also noted you only need the %hi/%lo 
variant due to the `-msym32' restriction for 64-bit DECstation kernels; 
the kernel is always linked to KSEG0.

 Alternatively for maximum safety perhaps we could define PTR_LA_EXPLICIT 
or suchlike with a suitable open-coded sequence for the pointer width 
chosen; note however that `-msym32' doesn't set any CPP's internal 
predefined macro, so we'd have to define our own to control this.

> Maciej, can you test this?

 I'll see what I can do; I've been travelling a lot lately.

  Maciej

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ