Re: [PATCHv9 2.6.35-rc4-tip 10/13] perf: Re-Add make_absolute_path

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

Em Mon, Jul 12, 2010 at 09:03:57PM +0530, Srikar Dronamraju escreveu:
> * Arnaldo Carvalho de Melo <acme@infradead.org> [2010-07-12 11:00:23]:
> > Em Mon, Jul 12, 2010 at 04:04:12PM +0530, Srikar Dronamraju escreveu:
> > > perf probe for uprobes would use make_absolute_path.
> > > make_absolute_path can be used to convert a file name to a dso name.

> > > so if user specifies the function to be traced as malloc@/lib/libc.so.6
> > > it needs to be converted to malloc@libc-2.5.so

> > Isn't this the other way around? I.e. "if the user specifies
> > malloc@libc-2.5.so it needs to be converted to malloc@/lib/libc.so.6"?

> Actually we dont need to convert malloc@libc-2.5.so to a
> malloc@/lib/libc.so.6. Because we can match the shortname of the dso. 

Humm, I see, it is path based, so the first libc-2.5.so that appears in
the LD_LIBRARY_PATH equivalent used in this code will be user, is that
right?

I.e. if I'm testing some new libc-2.5.so that provides, say, private
futexes while the one in my distro still doesn't have this feature, I'll
have to specify the absolute name or make sure it is before the system's
libc-2.5.so in the LD_LIBRARY_PATH, right?
 
> Problem will occur when users specifies a full path of the file.
> Since the file can refer to a symbolic link and the dso will have just
> the short name or the target file name. Here I am using
> make_absolute_path to resolve to the target file.
> Now we can then either check on dso full names or short names.
> I have chosen to use the short name.

Humm, so what you want is one of:

realpath - return the canonicalized absolute pathname
canonicalize_file_name -  return the canonicalized filename

Can you please check the man pages for both before we decide
re-introducing make_absolute_path?
 
> > Also please remove the xstrdup and die calls from this function, we're
> > trying to get rid of all such 'panic' like functions so that we can
> > librarize as much code as possible.
> 
> Okay, Can I do that in subsequent versions of the patchset?

yeah, its ok if you don't end up using one of the suggested libc
functions above :-)

- Arnaldo