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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 17 Feb 2020 16:46:09 +0000 From: Will Deacon <will@...nel.org> To: Vincenzo Frascino <vincenzo.frascino@....com> Cc: Nathan Chancellor <natechancellor@...il.com>, linux-arch@...r.kernel.org, ndesaulniers@...gle.com, 0x7f454c46@...il.com, avagin@...nvz.org, arnd@...db.de, sboyd@...nel.org, catalin.marinas@....com, x86@...nel.org, will.deacon@....com, linux-kernel@...r.kernel.org, linux-mips@...r.kernel.org, clang-built-linux@...glegroups.com, paul.burton@...s.com, mingo@...hat.com, bp@...en8.de, luto@...nel.org, linux@...linux.org.uk, tglx@...utronix.de, salyzyn@...roid.com, pcc@...gle.com, linux-arm-kernel@...ts.infradead.org Subject: Re: [PATCH 19/19] arm64: vdso32: Enable Clang Compilation On Mon, Feb 17, 2020 at 12:26:16PM +0000, Vincenzo Frascino wrote: > On 13/02/2020 18:44, Nathan Chancellor wrote: > > On Thu, Feb 13, 2020 at 04:16:14PM +0000, Vincenzo Frascino wrote: > >> Enable Clang Compilation for the vdso32 library. > > [...] > > >> +LD_COMPAT ?= $(CROSS_COMPILE_COMPAT)gcc > > > > Well this is unfortunate :/ > > > > It looks like adding the --target flag to VDSO_LDFLAGS allows > > clang to link the vDSO just fine although it does warn that -nostdinc > > is unused: > > > > clang-11: warning: argument unused during compilation: '-nostdinc' > > [-Wunused-command-line-argument] > > > > This is why ended up in this "unfortunate" situation :) I wanted to avoid the > warning. > > > It would be nice if the logic of commit fe00e50b2db8 ("ARM: 8858/1: > > vdso: use $(LD) instead of $(CC) to link VDSO") could be adopted here > > but I get that this Makefile is its own beast :) at the very least, I > > think that the --target flag should be added to VDSO_LDFLAGS so that gcc > > is not a requirement for this but I am curious if you tried that already > > and noticed any issues with it. > > > > --target is my preferred way as well, I can try to play another little bit with > the flags and see what I can come up with in the next version. Yes, please. I'd even prefer the warning rather than silently assuming that a cross gcc is kicking around on the path. Will
Powered by blists - more mailing lists