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

[Borislav Petkov]

On Sat, May 27, 2023 at 02:17:43AM -0700, Nadav Amit wrote:
> That’s not according to the symbol table - that’s in your mind.

s/your mind/objdump/

Objdump takes the next symbol's address as the end of the previous one.

> Anyhow, the argument that __get_user_nocheck_8 and bad_get_user_clac are
> related makes no sense even conceptually.

I don't think anyone's making that argument. Maybe you should read again what I
said:

"the exception handling ends up being part of __get_user_nocheck_8"

> Some people would even say “elementary”. I was sure it was already clear.

Your cocky attitude will get you nowhere. But whatever you prefer.

> I appreciate your help, but I have reasonable workarounds for my use-case
> (and for the record, no, I don’t think that this solution that you
> propose is reasonable).

I'm simply stating what objdump does. I guess objdump is not good enough
for you.

> It is not “a new tool". You screw up every tool that tries to understand

I'm not screwing up anything - that's your claim.

> All the other local symbols are irrelevant to the discussion as they fall
> within some other symbol's range.

As does this one if you deal with it just like objdump does.

> You are not (not) helping me. I am trying to help you (and other users).

Gee, thanks. I didn't know this needed any help.

> So just don’t do such weird things.

Yah, good luck with that. If it needs to be done in a weird way and it
is the *right* thing to do for the kernel, I couldn't care less about
some external tools.

As to what you want to address, I'll talk to toolchain folks first and
get back to you.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette