On Sun, May 22, 2022 at 04:56:08PM +0300, Alper Nebi Yasak wrote: > On 21/05/2022 15:05, Tom Rini wrote: > > On Sat, May 21, 2022 at 08:33:56AM +0000, Peng Fan wrote: > >>> Subject: Re: [PATCH V4 1/8] spl: guard u_boot_any with X86 > >>> > >>> On Fri, May 20, 2022 at 10:10:40PM +0800, Peng Fan (OSS) wrote: > >>> > >>>> From: Peng Fan <peng....@nxp.com> > >>>> > >>>> set the symbol as weak not work if LTO is enabled. Since u_boot_any is > >>>> only used on X86 for now, so guard it with X86, otherwise build break > >>>> if we use BINMAN_SYMBOLS on i.MX. > >>>> > >>>> Tested-by: Tim Harvey <thar...@gateworks.com> #imx8m[m,n,p]-venice > >>>> Signed-off-by: Peng Fan <peng....@nxp.com> > >>>> --- > >>>> common/spl/spl.c | 8 ++++++-- > >>>> common/spl/spl_ram.c | 4 ++++ > >>>> 2 files changed, 10 insertions(+), 2 deletions(-) > >>> > >>> I think we long term need to figure this out and address it so LTO works. > >>> But > >>> for now can you please guard this with a test on LTO instead, so it's > >>> clear > >>> where the problem is? > >> > >> Sorry, I could not get your point about guard with a test on LTO. > >> > >> Actually binman weak symbol will report a warning log if there is no > >> u_boot_any > >> binman symbol. Since only X86 use it, I guard with X86. > > > > Why are you mentioning LTO in the commit message? When I read the > > commit message it sounds like you're saying the problem is that LTO > > doesn't like how this symbol is handled, but if LTO was disabled, > > everything would be fine. If it's not LTO-related, please re-word the > > message instead. > > It looks like we should be able to change things in common/spl/spl.c to: > > #if CONFIG_IS_ENABLED(BINMAN_SYMBOLS) > /* See spl.h for information about this */ > binman_sym_declare_optional(ulong, u_boot_any, image_pos); > binman_sym_declare_optional(ulong, u_boot_any, size); > #endif > > which would mark the symbol as 'weak' and turn the error into a warning > on the binman side. But that is somehow being undone by LTO.
So, looking at binman_sym_declare_optional we tell the linker that it's weak and might even be unused. LTO gets very aggressive about finding things that aren't used in the resulting binary and discarding them. Typically we have the problem of a function that is used but it's hard for LTO to see it, so we give it the "used" attribute. But for something we're already saying is "unused" this would be wrong. So why do we mark things as unused here? I assume it's marked weak as it could be overridden at link time by a definition elsewhere. -- Tom
signature.asc
Description: PGP signature