[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <45f3e718a0c046f9a11f49eb199d425c@AcuMS.aculab.com>
Date: Mon, 15 Mar 2021 10:57:49 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Nick Desaulniers' <ndesaulniers@...gle.com>,
Masahiro Yamada <masahiroy@...nel.org>
CC: Sami Tolvanen <samitolvanen@...gle.com>,
Candle Sun <candlesea@...il.com>,
Fangrui Song <maskray@...gle.com>,
Michal Marek <michal.lkml@...kovi.net>,
Nathan Chancellor <nathan@...nel.org>,
Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
clang-built-linux <clang-built-linux@...glegroups.com>
Subject: RE: [PATCH] Makefile: LTO: have linker check -Wframe-larger-than
From: Nick Desaulniers
> Sent: 12 March 2021 17:55
>
> On Thu, Mar 11, 2021 at 5:09 PM Nick Desaulniers
> <ndesaulniers@...gle.com> wrote:
> >
> > -Wframe-larger-than= requires stack frame information, which the
> > frontend cannot provide. This diagnostic is emitted late during
> > compilation once stack frame size is available.
> >
> > When building with LTO, the frontend simply lowers C to LLVM IR and does
> > not have stack frame information, so it cannot emit this diagnostic.
> > When the linker drives LTO, it restarts optimizations and lowers LLVM IR
> > to object code. At that point, it has stack frame information but
> > doesn't know to check for a specific max stack frame size.
With LTO the linker ought to be able to do a stack frame check
across multiples functions in the call stack.
Clearly recursive calls cause issues.
Indirect ones as well - but does CFI include enough info
about what can be called from where to help?
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists