[PATCH V4 1/8] spl: guard u_boot_any with X86

[Tom Rini]

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.fan at 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 <tharvey at gateworks.com> #imx8m[m,n,p]-venice
> >>>> Signed-off-by: Peng Fan <peng.fan at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20220522/58625b8c/attachment.sig>