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

From: Jiri Slaby
Date: Tue Nov 22 2022 - 04:32:33 EST


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