Re: perf's handling of unfindable user symbols...

[David Miller]

From: Arnaldo Carvalho de Melo <acme@xxxxxxxxxx>
Date: Mon, 15 Oct 2018 19:25:46 -0300

> But I think we should have it as a property of 'struct machine', because we may
> be processing on, say, x86, a perf.data file recorded on a Sparc machine, so we
> need to save this property on the perf.data file, humm, or we can derive that
> from data already there, like the quick patch below. I'll cache that property
> on machine->user_kernel_shared_address_space, to avoid having to do the
> strcmp() lots of times.
> 
> Does that document the hack further? Defining the
> machine__user_kernel_shared_address_space() function right besides the
> machine__kernel_ip() inline should help as well?

Your patch looks fine.

But, more deeply, the VDSO thing itself makes no sense to me.

Why would we use the kernel map for something that is mapped into
userspace and uses the user space virtual addresse range?

As it is used by user applications, the VDSO isn't mapped into the
kernel virtual address range, therefore no PC from userspace executing
the VDSO will have a kernel range address.

We will see normal userspace virtual addresses instead.  Test this
assertion, if you like :-)

So I am suggesting that we remove the hack, and don't try to use the
kernel map for resolving the IP of user mode events.  If that is a
valid change, we can toss all of this weird stuff that tries to
interpret an address based upon what "range" it falls into.