Re: [PATCH v3 1/7 UPDATE2] perf tools: Find vdso with the consider of cross-platform

[Arnaldo Carvalho de Melo <acme@kernel.org>]

Em Thu, Jun 16, 2016 at 04:00:12PM +0300, Adrian Hunter escreveu:
> On 15/06/16 16:34, Arnaldo Carvalho de Melo wrote:
> > Em Tue, May 17, 2016 at 09:04:54AM +0000, He Kuang escreveu:
> >> There's a problem in machine__findnew_vdso(), vdso buildid generated
> >> by a 32-bit machine stores it with the name 'vdso', but when
> >> processing buildid on a 64-bit machine with the same 'perf.data', perf
> >> will search for vdso named as 'vdso32' and get failed.
> > 
> > Without looking at the code, just trying to understand your patch by
> > reading your description: Why would we look for names if we have
> > build-ids? All this type and name comparasions seems wrong if we have a
> > build-id, no?
> > 
> > Adrian?
> 
> We match maps to builds ids using the file name - consider
> machine__findnew_[v]dso() called in map__new().  So in the context of a perf
> data file, we consider the file name to be unique.
> 
> A vdso map does not have a file name - all we know is that it is vdso.  We
> look at the thread to tell if it is 32-bit, 64-bit or x32.  Then we need to
> get the build id which has been recorded using short name "[vdso]" or
> "[vdso32]" or "[vdsox32]".
> 
> The problem is that on a 32-bit machine, we use the name "[vdso]".  If you
> take a 32-bit perf data file to a 64-bit machine, it gets hard to figure out
> if "[vdso]" is 32-bit or 64-bit.
> 
> This patch solves that problem.
> 
> I acked it in another email.

Ok, somehow this got lost, I thought to have applied it already, but
re-reading the changeset comment, I got confused, thanks for providing
this explanation, that I will stick to the changeset log for this
message, to help understanding this when scratching our heads in the
future.

- Arnaldo