On Tue, Jun 09, 2020 at 04:55:13PM -0700, Nick Desaulniers wrote: > On Tue, Jun 9, 2020 at 1:35 PM Catalin Marinas <catalin.mari...@arm.com> > wrote: > > > > On Mon, Jun 08, 2020 at 01:57:08PM -0700, Nick Desaulniers wrote: > > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig > > > index 7f9d38444d6d..fe9e6b231cac 100644 > > > --- a/arch/arm64/Kconfig > > > +++ b/arch/arm64/Kconfig > > > @@ -1299,6 +1299,14 @@ config COMPAT_VDSO > > > You must have a 32-bit build of glibc 2.22 or later for programs > > > to seamlessly take advantage of this. > > > > > > +config THUMB2_COMPAT_VDSO > > > + bool "Compile the vDSO in THUMB2 mode" > > > + depends on COMPAT_VDSO > > > + default y > > > + help > > > + Compile the compat vDSO with -mthumb -fomit-frame-pointer if y, > > > otherwise > > > + as -marm. > > > > Now that we understood the issue (I think), do we actually need this > > choice? Why not going for -mthumb -fomit-frame-pointer always for the > > compat vdso? > > "Why should the compat vdso be configurable?" is a fair question. I > don't have an answer, but maybe some of the folks on thread do? > > Our problem is more so "if the vdso is built as thumb, we need it also > explicitly built with -fomit-frame-pointer." Whether it should be > built as thumb, arm, or configurable (and which default to pick in > that case) are still an open questions. Will asked for it to be > configurable, so I sent a patch making it configurable.
It's configurable for 32-bit arm, so I was just following that as it's hardly a maintenance burden to support both. I suppose you could have a toolchain that only supports one or the other, but it does seem a little esoteric if you're building a kernel for an arm64 CPU. Will