Re: Is there a way to override the symbol check for a specific file (or set)?

[Maynard J. <may...@us...>]

Randell Jesup wrote:
>> Randell Jesup wrote:
>>> I'm using Oprofile 0.9.6, running natively on an ARM under 2.6.10 with
>>> kernel support.
>>>
>>> I'm trying to look at a profile on an embedded device (where the
>>> binaries are typically stripped and readonly/compressed).  I have access
>>> to vmlinux and the un-stripped binaries/libraries in a sub-tree (not a
>>> full filesystem image: --root doesn't work).
>>>
>>> The problem is that even with --image-path, opreport seems to use the
>>> original file to fetch the symbols from.  Since the original location is
>>> read-only, I can't replace it with the with-symbols copy.  I've tried a
>>> number of variations on --image-path; --root doesn't work, and I've
>>> tried looking at the app, the library directly, etc.
>>>
>>> Any way to override debug symbol reading and make image-path take
>>> precedence if the image is found?  (Or at least if no symbols are found
>>> in the canonical location)?
>> If opreport does not find symbol info in the sampled binary, it checks to
>> see if it contains a gnu-debuglink that indicates a separate debuginfo file
>> has been created.  If so, there are several standard locations opreport
>> will look for the debuginfo file.
> 
> I see that check, but the library doesn't have a .gnu-debuglink section.
> 
>> If you pass an image-path argument, it will look there, too.
> 
> The attached --verbose=all log doesn't seem to indicate that it is.  I

It will do this *only* if it finds the gnu-debuglink.

> tried using the "root" of the sub-tree like --image-path=/my/image-path
> (assuming if it's looking for /usr/lib/libxyzzy.so.4 that it will then
> try /my/image-path/usr/lib/libxyzzy.so.4), and I tried passing the full
> path of the directory where the library is
> (--image-path=/my/image-path/usr/lib)
> 
>> Most distros will provide separate debuginfo files
>> for libraries.  If this is a distro-supplied library and there's a
>> corresponding debuginfo rpm, then just install that rpm -- no need to use
>> --image-path.  If you (or someone else) builds the library in question,
>> then make sure a separate debuginfo file is created.  You can place the
>> debuginfo file anywhere you want on the target system, and use the
>> --image-path to tell opreport to look there.
> 
> The docs for --image-path make no mention of gnu_debuginfo; from the
> description the argument should make it look for alternate images with
> symbols.  If it's only for .gnu_debuginfo, then it should be
> named --debuginfo_path, not --image_path (IMHO).

Over time, the purpose of --image-path has evolved, and unfortunately, the man 
page did not keep up with that evolution.  I was never personally involved with 
the functionality surrounding this option, so it would take some time for me to 
scour the code to describe all of its uses.  I don't have time to address this 
right now.  Maybe someone else would like to volunteer?.  Please open a bugzilla 
so that this issue doesn't fall through the cracks.

> 
>> For a binary 'foo' that initially contains debug info . . .
>> $ objcopy --only-keep-debug foo foo.debuginfo
>> $ objcopy --strip-debug foo
>> $ objcopy --add-gnu-debuglink=foo.debuginfo  foo
> 
> That last command (inserting the .gnu-debuglink section) is a problem,
> since this is a read-only image.  Not insurmountable, but very painful
> to do to hundreds of libraries, then regenerate a image, get it into the

Hundreds?  Curious why you would need to profile hundreds of libraries. It's 
pretty typical when I do a profile on a system to see lots of samples in 
libraries that are stripped.  But I use the --separate=lib opcontrol option, so 
I'm only focusing on the application of interest and the libraries it uses.  If 
I find a real need to see symbol info in system libs that are stripped, I 
install the distro's debuginfo rpm.  If your distro does not supply debuginfo 
rpms and yet it super-strips the libraries, that's a problem.

> read-only target, etc.  And then it's not the same image, which affects
> testing criteria.  If I didn't have the option of changing the load
> (true read-only), I'd be SOL.

Have you considered using oparchive and then doing the post-processing on a 
different system?  Maybe you could figure out how to get a host environment 
setup with non-stripped binaries to use with opreport.  I don't ever work in an 
embedded environment, so I'm not the best person to advise you on this. 
*Richard*, any  tips for Randell?

-Maynard

> 
[snip]