I was using elfutils version 0.175, since we download the lastest. But after moving back to 0.173, this problem disappeared. So, some update after 0.173 broke this.
Sasha From: Sasha Da Rocha Pinheiro Sent: Tuesday, February 12, 2019 12:49 PM To: Mark Wielaard Cc: elfutils-devel@sourceware.org; Ben Woodard Subject: Re: unknown error after dwarf_cfi_addrframe() Since the openbackend() tries to dlopen twice, and in the second turn it succeeds opening one libebl_x86_64.so, I even tried to redirect that symbolic link to a newer version of libebl_x86_64-0.165.so, as seen below. (gdb) shell [sasha@zatar] (1)$ locate libebl /usr/lib/x86_64-linux-gnu/elfutils/libebl_aarch64-0.165.so /usr/lib/x86_64-linux-gnu/elfutils/libebl_aarch64.so /usr/lib/x86_64-linux-gnu/elfutils/libebl_alpha-0.165.so /usr/lib/x86_64-linux-gnu/elfutils/libebl_alpha.so /usr/lib/x86_64-linux-gnu/elfutils/libebl_arm-0.165.so /usr/lib/x86_64-linux-gnu/elfutils/libebl_arm.so /usr/lib/x86_64-linux-gnu/elfutils/libebl_i386-0.165.so /usr/lib/x86_64-linux-gnu/elfutils/libebl_i386.so /usr/lib/x86_64-linux-gnu/elfutils/libebl_ia64-0.165.so /usr/lib/x86_64-linux-gnu/elfutils/libebl_ia64.so /usr/lib/x86_64-linux-gnu/elfutils/libebl_m68k-0.165.so /usr/lib/x86_64-linux-gnu/elfutils/libebl_m68k.so /usr/lib/x86_64-linux-gnu/elfutils/libebl_mips-0.165.so /usr/lib/x86_64-linux-gnu/elfutils/libebl_mips.so /usr/lib/x86_64-linux-gnu/elfutils/libebl_parisc-0.165.so /usr/lib/x86_64-linux-gnu/elfutils/libebl_parisc.so /usr/lib/x86_64-linux-gnu/elfutils/libebl_ppc-0.165.so /usr/lib/x86_64-linux-gnu/elfutils/libebl_ppc.so /usr/lib/x86_64-linux-gnu/elfutils/libebl_ppc64-0.165.so /usr/lib/x86_64-linux-gnu/elfutils/libebl_ppc64.so /usr/lib/x86_64-linux-gnu/elfutils/libebl_s390-0.165.so /usr/lib/x86_64-linux-gnu/elfutils/libebl_s390.so /usr/lib/x86_64-linux-gnu/elfutils/libebl_sh-0.165.so /usr/lib/x86_64-linux-gnu/elfutils/libebl_sh.so /usr/lib/x86_64-linux-gnu/elfutils/libebl_sparc-0.165.so /usr/lib/x86_64-linux-gnu/elfutils/libebl_sparc.so /usr/lib/x86_64-linux-gnu/elfutils/libebl_tilegx-0.165.so /usr/lib/x86_64-linux-gnu/elfutils/libebl_tilegx.so /usr/lib/x86_64-linux-gnu/elfutils/libebl_x86_64-0.165.so /usr/lib/x86_64-linux-gnu/elfutils/libebl_x86_64.so [sasha@zatar] (2)$ ls -la /usr/lib/x86_64-linux-gnu/elfutils/libebl_x86_64.so lrwxrwxrwx 1 root root 70 Feb 12 12:25 /usr/lib/x86_64-linux-gnu/elfutils/libebl_x86_64.so -> /p/paradyn/development/sasha/local/lib/elfutils/libebl_x86_64-0.175.so* [sasha@zatar] (3)$ Sasha From: Sasha Da Rocha Pinheiro Sent: Tuesday, February 12, 2019 12:41 PM To: Mark Wielaard Cc: elfutils-devel@sourceware.org; Ben Woodard Subject: Re: unknown error after dwarf_cfi_addrframe() Below I copy gdb execution from eblopenbackend.c trying to dlopen a dsoname "libebl_x86_64.so". After that it will try to open again, which find something, but culminates to closing it with (void) dlclose (h); (gdb) n 328 void *h = dlopen (dsoname, RTLD_LAZY); (gdb) p dsonmae No symbol "dsonmae" in current context. (gdb) p dsoname $97 = "$ORIGIN/../$LIB/elfutils/libebl_x86_64.so\000\242\001\000\000\000\000\300\317\377\377\377\177\000\000\240N\242\001\000\000\000\000\220\317\377\377\377\177\000\000U\236o\357\377\177\000\000\300\317\377\377\377\177\000\000\240N\242\001\000\000\000\000\000\000\000" (gdb) show environment $ORIGIN Environment variable "$ORIGIN" not defined. (gdb) show environment $LIB Environment variable "$LIB" not defined. (gdb) n 329 if (h == NULL) (gdb) p h $98 = (void *) 0x0 (gdb) show environment LD_LIBRARY_PATH LD_LIBRARY_PATH = /p/paradyn/development/sasha/local/lib/elfutils/:/p/paradyn/development/sasha/local/lib/:/p/paradyn/packages/libdwarf/lib:. (gdb) ls /p/paradyn/development/sasha/local/lib/elfutils/ Undefined command: "ls". Try "help". (gdb) shell [sasha@zatar] (1)$ ls /p/paradyn/development/sasha/local/lib/elfutils/ libebl_aarch64-0.175.so* libebl_i386-0.175.so* libebl_ppc64.so@ libebl_sparc-0.175.so* libebl_aarch64.so@ libebl_i386.so@ libebl_ppc.so@ libebl_sparc.so@ libebl_alpha-0.175.so* libebl_ia64-0.175.so* libebl_riscv-0.175.so* libebl_tilegx-0.175.so* libebl_alpha.so@ libebl_ia64.so@ libebl_riscv.so@ libebl_tilegx.so@ libebl_arm-0.175.so* libebl_m68k-0.175.so* libebl_s390-0.175.so* libebl_x86_64-0.175.so* libebl_arm.so@ libebl_m68k.so@ libebl_s390.so@ libebl_x86_64.so@ libebl_bpf-0.175.so* libebl_ppc-0.175.so* libebl_sh-0.175.so* libebl_bpf.so@ libebl_ppc64-0.175.so* libebl_sh.so@ [sasha@zatar] (2)$ exit exit (gdb) frame #0 openbackend (elf=0x1a24ea0, emulation=0x0, machine=62) at /p/paradyn/development/sasha/dyninst/build.dir/elfutils/src/LibElf/libebl/eblopenbackend.c:329 329 if (h == NULL) (gdb) From: Sasha Da Rocha Pinheiro Sent: Tuesday, February 12, 2019 11:57 AM To: Mark Wielaard Cc: elfutils-devel@sourceware.org; Ben Woodard Subject: Re: unknown error after dwarf_cfi_addrframe() Not working even after adding the directory to libebl_*.so to LD_LIBRARY_PATH. default_abi_cfi is still called returning -1. Sasha From: Mark Wielaard <m...@klomp.org> Sent: Tuesday, February 12, 2019 2:09 AM To: Sasha Da Rocha Pinheiro Cc: elfutils-devel@sourceware.org; Ben Woodard Subject: Re: unknown error after dwarf_cfi_addrframe() On Tue, Feb 12, 2019 at 07:25:28AM +0000, Sasha Da Rocha Pinheiro wrote: > Oh this is a whole new thing. How have this worked before without those .so? > After downloading and compiling elfutils we only copy libdw and libelf. The backends are only used for architecture specific ELF things. Most of DWARF can be understood in an architecture independent way. But CFI does have some arch specific things. You should really use make install to get a proper installation, not just copy some files. Otherwise you might indeed miss the backends, or translations, etc. Cheers, Mark
