Re: [PATCH 18/46] entry, lto: Mark raw_irqentry_exit_cond_resched() as __visible

[Jiri Slaby]

Hi,

On 17. 11. 22, 0:30, Thomas Gleixner wrote:
> On Mon, Nov 14 2022 at 12:43, Jiri Slaby wrote:
> > Symbols referenced from assembler (either directly or e.f. from
>
> from assembler? I'm not aware that the assembler references anything.

"""
Noun assembler

assembler (countable and uncountable, plural assemblers)

1.  (programming, countable) A program that reads source code written in 
assembly language and produces executable machine code, possibly 
together with information needed by linkers, debuggers and other tools.

2. (computer languages, informal, chiefly uncountable) Assembly language.

    I wrote that program in assembler.
""" [1]

I refer in the above to 2. You refer to 1.

In some languages, incl. mine, we don't distinguish between the two. 
It's always assembler. Yet, that might confuse you, even though it's 
correct as you can see above. I can switch to mode 1 (assembler and 
assembly) for sure.

[1] https://en.wiktionary.org/wiki/assembler

> Also what does e.f. mean? Did you want to write e.g.?

Yes, my and my spellchecker's bad.

> > DEFINE_STATIC_KEY()) need to be global and visible in gcc LTO because
> > they could end up in a different object file than the assembler. This
>
> than the assembler? Are we shipping the assembler in an object file?

Nope, see above.

> > can lead to linker errors without this patch.
>
> git grep -i 'this patch' Documentation/process/

Sorry, I don't understand, care to elaborate? None of the lines from the 
output seems to match the case here.

> > So mark raw_irqentry_exit_cond_resched() as __visible.
>
> And all that tells me what? I know what you want to say, but it's not
> there.
>
>    Symbols in different compilation units which are referenced from
>    assembly code either directly or indirectly, e.g. from
>    DEFINE_STATIC_KEY(), must be marked visible for GCC based LTO builds.
>
>    Add the missing __visible annotation to raw_irqentry_exit_cond_resched().
>
> See?
>
> There is no 'global' because it's obvious that a symbol in a different
> compilation unit must be global to be resolvable. It's also obvious that
> code in different compilation units ends up in different object files.

It's not about different compilation units. It's about different partitions.

> So stating that it's a 'must' to have such symbols marked visible is
> good enough for an argument because that tells the reader that this is a
> mandatory requirement for an GCC based LTO build.

My bad that I failed to explain properly in the commit log. But we are 
working on throwing all this __visible thing away. Agreed, that it's 
ridiculous/absurd.

thanks,
--
js
suse labs