gprofng -- no function info even when compiling with -g

Vladimir Mezentsev vladimir.mezentsev@oracle.com
Thu May 18 20:15:40 GMT 2023


Hi Joe,

On 5/18/23 10:26, Joe Matarazzo via Binutils wrote:
> Have an app that I'm trying to profile with gprofng. The app is compiled on
> another machine in a Docker container and then copied to the test machine.
> The source is compiled with "-g".
>
> I downloaded and built gprofng on the test machine. I didn't install all
> the other binutils components as it already has an existing version of
> binutils that I didn't want to overwrite. I'm hoping that's not a problem.
>
> Steps:
> 1. gprofng collect app <cmd line>
> 2. gprofng display test -lines test.1.er

s/test/text/

>
> Results:
> Excl. Total    Incl. Total     Name
> CPU            CPU
>    sec.      %    sec.      %
> 88.242 100.00  88.242 100.00   <Total>
> 43.300  49.07  67.767  76.80   <Function: <static>@0x0 (<libFoo.so>) --  no
> functions found, instructions without line numbers>

"<static>@0x0 (<libFoo.so>) -- no functions found" is a fake name.
"-- no functions found" is removed in 
sourceware.org/git/binutils-gdb.git (commit: b5fbb4c2b46 gprofng: 
include a new function in the right place).

gprofng maps PC to a fake function such as <static>@0x0 (<libFoo.so>) when gprofng cannot find the real function in <libFoo.so> that contains this PC.
This usually happens for static functions in a stripped library.
Did you strip libFoo.so ?


gprofng reports "instructions without line numbers" when gprofng cannot read DWARF.
Do you see DWARF (`objdump -W libFoo.so`) on your test machine ? On your build machine ?

Run:
   gprofng display text -name long:soname -pcs test.1.er

Do you see line numbers ?
  

> where libFoo is part of my app.
>
> Does the source itself need to be copied to the test machine?

No for `gprofng display text -lines`.
We need only object files with debug information.


>   My experience
> with regular "gprof" didn't reflect that requirement. It was able to report
> function names just fine with
>
> gprof /path/to/executable gmon.out
>
> One other piece of information -- when I ran `gprofng display test`
> interactively, and tried the "header" command, it gave a bunch of warnings
> about not being able to open the dependencies:
>
> *** Warning: Can't open file: /lib/libpthread.so.0
> *** Warning: Can't open file: /lib/libgcc_s.so.1
> *** Warning: Can't open file: /lib/libm.so.6
> *** Warning: Can't open file: /usr/lib/libstdc++.so.6.0.29

> Steps:
> 1. gprofng collect app <cmd line>
> 2. gprofng display test -lines test.1.er


Were your steps ? On one machine ? Or step (2) was on the other machine ?
Did you reinstall libraries (`yum update`) between (1) and (2) ?
Do you see files inside test.1.er/archives ?

Thank you,
-Vladimir

>
> Thought maybe something similar was happening when running
> non-interactively but it just wasn't getting printed.
>
> Thanks,
> Joe



More information about the Binutils mailing list