Comment # 3 on bug 1180610 from Martin Li������ka

All right, there's a small reproducer:

$ cat main.cpp
int x = 12345;
int foo(void);

int main()
{
  for (int i = 0; i < 100000000; i++)
  {
    foo ();
    x = (x * 123) % 17;
  }
  return 0;
}

$ cat foo.c
int foo(void)
{
  return 123;
}

$ cat cmd
g++ -shared -O2 -g -fPIC -flto foo.c -o libfoo.so
gcc main.cpp -g -lfoo -L.
LD_LIBRARY_PATH=. perf record ./a.out
LD_LIBRARY_PATH=. perf report --stdio | grep libfoo

$ ./cmd
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.080 MB perf.data (2055 samples) ]
     4.57%  a.out    libfoo.so         [.] 0x0000000000001100

The problematic symbol is:

$ readelf -s libfoo.so | grep foo.c
    59: 0000000000000067     0 NOTYPE  LOCAL  DEFAULT   25 foo.c.85ed61de

I added a debugging line to perf:
XXX:elf_getscn:
/home/marxin/.debug/.build-id/41/a1b578a6ea78ae8ae8d60e791a4facfa108775/elf: 25

The problem is related to LTO (removal of -flto from 'g++ -shared -O2 -g -fPIC
-flto foo.c -o libfoo.so') works fine.

What happens: we create so called early LTO object file:

$ readelf -s foo.o.debug.temp.o

Symbol table '.symtab' contains 27 entries:
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND 
     1: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS foo.c
...
    25: 0000000000000000     0 NOTYPE  WEAK   HIDDEN     1 foo.c.85ed61de

which is some kind of placeholder for LTO (if I'm correct).
Anyway, one obvious fix is to learn perf that only symbols of type 'FUNC'
should be considered in dso__load_sym.