Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S936327AbcKDQJv (ORCPT ); Fri, 4 Nov 2016 12:09:51 -0400 Received: from mailapp01.imgtec.com ([195.59.15.196]:37903 "EHLO mailapp01.imgtec.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935415AbcKDQJu (ORCPT ); Fri, 4 Nov 2016 12:09:50 -0400 Date: Fri, 4 Nov 2016 16:09:37 +0000 From: "Maciej W. Rozycki" To: Guenter Roeck CC: Matthew Fortune , Ralf Baechle , "linux-mips@linux-mips.org" , "linux-kernel@vger.kernel.org" , James Hogan Subject: Re: [PATCH] MIPS: VDSO: Always select -msoft-float In-Reply-To: <20161104152603.GB12009@roeck-us.net> Message-ID: References: <1477843551-21813-1-git-send-email-linux@roeck-us.net> <20161101233038.GA25472@roeck-us.net> <6D39441BF12EF246A7ABCE6654B0235380AB79B7@HHMAIL01.hh.imgtec.org> <20161104152603.GB12009@roeck-us.net> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [10.20.78.29] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1113 Lines: 24 On Fri, 4 Nov 2016, Guenter Roeck wrote: > > As above, unless absolutely critical to have floating point code then > > the vDSO should just avoid all FP related issues and build soft-float. > > FWIW, my logic was quite simple: The rest of the kernel builds with > -msoft-float, thus vDSO should do the same. Of course, I don't know the > entire context, so there may well be a reason to handle it differently > than the rest of the kernel. VDSO is not a part of the kernel, it's user mode code, made visible in the user virtual memory, and implicitly loaded along the rest of the DSOs on program startup by the dynamic loader (ld.so). It has to be PIC for that reason, too, causing all the hassle we had with making it such that it does not need a GOT. > Anyway, isn't the kernel supposed to not use floating point operations > in the first place ? Is this different for vDSO ? This code is executed in the user mode so while floating-point code may not be needed there, not at least right now, there's actually nothing which should stop us from from adding some should such a need arise. Maciej