Re: [PATCH v2] x86/lib: Do not use local symbols with SYM_CODE_START_LOCAL()

[Nadav Amit <nadav.amit@gmail.com>]

> On May 26, 2023, at 1:45 PM, Borislav Petkov <bp@alien8.de> wrote:
> 
> On Fri, May 26, 2023 at 10:29:29AM -0700, Nadav Amit wrote:
>> Can you give me some examples for code whose address cannot be mapped
>> back to a symbol?
> 
> No, this is not what I'm talking about.
> 
> I'm talking about all the local labels the compiler uses. For example:
> 
> $ make kernel/sched/core.s
> $ grep -E "^\.L" kernel/sched/core.s | wc -l
> 2799
> 
> All those local labels are not in the symbol table (get discarded) and
> the addresses they represent are shown as belonging to the containing
> function.

Right. But the symbols I mentioned are not contained in any other symbol.
If you run gdb and try to disasm this bad_get_user_clac (its address),
you’d currently get "No function contains specified address”.

That what makes these 2 symbols different than the others.

> 
>> I did not ask to make them global. Just to keep them as local after
>> linkage in the executable, like all other functions in the kernel.
> 
> Ok, not global. But local and present in the symbol table:
> 
> 105185: ffffffff81b89330    17 NOTYPE  LOCAL  DEFAULT    1 bad_get_user_clac
> 
> And again, this helps how exactly?

Allowing debuggers, tracers, disassemblers and instrumentation tools to
work the same way they work as they work with any other piece of code in
the kernel.

I personally work on code instrumentation and this makes my life hard for
no good reason.

[ Perhaps the question should go the other way around: why addresses of
code in these functions should not be mapped to any symbol? ]