Menu
▾
▴
valgrind-users
|
From: janjust <tja...@un...> - 2014-04-07 02:29:36
|
Hi, I'm trying to profile valgrind using perftools-lite and when compiling the tools I get an undefined reference error. VEX and coregrind build, but during linking it errs (error is below). I think it has do with static linking, the build command in memcheck was: ../coregrind/link_tool_exe_linux 0x38000000 cc -Wno-long-long -gdwarf-3 -gstrict-dwarf -Wwrite-strings -fno-stack-protector -o memcheck-amd64-linux -m64 -O2 -g -Wall -Wmissing-prototypes -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wno-format-zero-length -fno-strict-aliasing -fno-builtin -fno-omit-frame-pointer -O2 -nodefaultlibs -nostartfiles -u _start -Wl,--build-id=none -m64 memcheck_amd64_linux-mc_leakcheck.o memcheck_amd64_linux-mc_malloc_wrappers.o memcheck_amd64_linux-mc_main.o memcheck_amd64_linux-mc_translate.o memcheck_amd64_linux-mc_machine.o memcheck_amd64_linux-mc_errors.o ../coregrind/libcoregrind-amd64-linux.a ../VEX/libvex-amd64-linux.a -lgcc Does anyone have any suggestions on how to resolve this? ----- ../coregrind/libcoregrind-amd64-linux.a(libcoregrind_amd64_linux_a-m_main.o):/ccs/home/janjust/janjust_proj/valgrind-trunk/coregrind/m_main.c:2684: first defined here /opt/cray/xe-sysroot/4.2.34/usr/lib64/libpthread.a(pthread_once.o): In function `clear_once_control': /usr/src/packages/BUILD/glibc-2.11.3/nptl/../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_once.S:163: undefined reference to `_Unwind_Resume' /opt/cray/xe-sysroot/4.2.34/usr/lib64/libpthread.a(pthread_once.o):(.eh_frame+0x13): undefined reference to `__gcc_personality_v0' /opt/cray/xe-sysroot/4.2.34/usr/lib64/libpthread.a(unwind.o): In function `__pthread_unwind': /usr/src/packages/BUILD/glibc-2.11.3/nptl/unwind.c:130: undefined reference to `_Unwind_ForcedUnwind' /opt/cray/xe-sysroot/4.2.34/usr/lib64/libpthread.a(unwind.o): In function `unwind_stop': /usr/src/packages/BUILD/glibc-2.11.3/nptl/unwind.c:61: undefined reference to `_Unwind_GetCFA' /usr/src/packages/BUILD/glibc-2.11.3/nptl/unwind.c:72: undefined reference to `_Unwind_GetCFA' /opt/cray/xe-sysroot/4.2.34/usr/lib64/libc.a(iofclose.o): In function `_IO_acquire_lock_fct': /usr/src/packages/BUILD/glibc-2.11.3/libio/libioP.h:969: undefined reference to `_Unwind_Resume' /opt/cray/xe-sysroot/4.2.34/usr/lib64/libc.a(iofclose.o):(.eh_frame+0x21b): undefined reference to `__gcc_personality_v0' /opt/cray/xe-sysroot/4.2.34/usr/lib64/libc.a(iofflush.o): In function `_IO_acquire_lock_fct': /usr/src/packages/BUILD/glibc-2.11.3/libio/libioP.h:969: undefined reference to `_Unwind_Resume' /opt/cray/xe-sysroot/4.2.34/usr/lib64/libc.a(iofflush.o):(.eh_frame+0x14b): undefined reference to `__gcc_personality_v0' /opt/cray/xe-sysroot/4.2.34/usr/lib64/libc.a(iofwrite.o): In function `_IO_acquire_lock_fct': /usr/src/packages/BUILD/glibc-2.11.3/libio/libioP.h:969: undefined reference to `_Unwind_Resume' /opt/cray/xe-sysroot/4.2.34/usr/lib64/libc.a(iofwrite.o):(.eh_frame+0x14b): undefined reference to `__gcc_personality_v0' /opt/cray/xe-sysroot/4.2.34/usr/lib64/libc.a(wfileops.o): In function `_IO_acquire_lock_fct': /usr/src/packages/BUILD/glibc-2.11.3/libio/../libio/libioP.h:969: undefined reference to `_Unwind_Resume' /opt/cray/xe-sysroot/4.2.34/usr/lib64/libc.a(wfileops.o):(.eh_frame+0x14b): undefined reference to `__gcc_personality_v0' /opt/cray/xe-sysroot/4.2.34/usr/lib64/libc.a(fileops.o): In function `_IO_acquire_lock_fct': /usr/src/packages/BUILD/glibc-2.11.3/libio/libioP.h:969: undefined reference to `_Unwind_Resume' /opt/cray/xe-sysroot/4.2.34/usr/lib64/libc.a(fileops.o): In function `_IO_new_file_fopen': /usr/src/packages/BUILD/glibc-2.11.3/libio/fileops.c:409: undefined reference to `_Unwind_Resume' /opt/cray/xe-sysroot/4.2.34/usr/lib64/libc.a(fileops.o):(.eh_frame+0x14b): undefined reference to `__gcc_personality_v0' /opt/cray/xe-sysroot/4.2.34/usr/lib64/libc.a(syslog.o): In function `__libc_cleanup_routine': /usr/src/packages/BUILD/glibc-2.11.3/misc/../nptl/sysdeps/pthread/bits/libc-lock.h:432: undefined reference to `_Unwind_Resume' /usr/src/packages/BUILD/glibc-2.11.3/misc/../nptl/sysdeps/pthread/bits/libc-lock.h:432: undefined reference to `_Unwind_Resume' /usr/src/packages/BUILD/glibc-2.11.3/misc/../nptl/sysdeps/pthread/bits/libc-lock.h:432: undefined reference to `_Unwind_Resume' /usr/src/packages/BUILD/glibc-2.11.3/misc/../nptl/sysdeps/pthread/bits/libc-lock.h:432: undefined reference to `_Unwind_Resume' /opt/cray/xe-sysroot/4.2.34/usr/lib64/libc.a(syslog.o):(.eh_frame+0x21b): undefined reference to `__gcc_personality_v0' /opt/cray/xe-sysroot/4.2.34/usr/lib64/libc.a(backtrace.o): In function `__backtrace': /usr/src/packages/BUILD/glibc-2.11.3/debug/../sysdeps/x86_64/../ia64/backtrace.c:110: undefined reference to `_Unwind_Backtrace' /opt/cray/xe-sysroot/4.2.34/usr/lib64/libc.a(backtrace.o): In function `backtrace_helper': /usr/src/packages/BUILD/glibc-2.11.3/debug/../sysdeps/x86_64/../ia64/backtrace.c:80: undefined reference to `_Unwind_GetIP' /usr/src/packages/BUILD/glibc-2.11.3/debug/../sysdeps/x86_64/../ia64/backtrace.c:83: undefined reference to `_Unwind_GetCFA' /opt/cray/xe-sysroot/4.2.34/usr/lib64/libc.a(vfprintf_chk.o): In function `_IO_acquire_lock_clear_flags2_fct': /usr/src/packages/BUILD/glibc-2.11.3/debug/../libio/libioP.h:979: undefined reference to `_Unwind_Resume' /opt/cray/xe-sysroot/4.2.34/usr/lib64/libc.a(vfprintf_chk.o):(.eh_frame+0x14b): undefined reference to `__gcc_personality_v0' /opt/cray/xe-sysroot/4.2.34/usr/lib64/libc.a(iofputs.o): In function `_IO_acquire_lock_fct': /usr/src/packages/BUILD/glibc-2.11.3/libio/libioP.h:969: undefined reference to `_Unwind_Resume' /opt/cray/xe-sysroot/4.2.34/usr/lib64/libc.a(iofputs.o):(.eh_frame+0x14b): undefined reference to `__gcc_personality_v0' /opt/cray/xe-sysroot/4.2.34/usr/lib64/libc.a(ioftell.o): In function `_IO_acquire_lock_fct': /usr/src/packages/BUILD/glibc-2.11.3/libio/libioP.h:969: undefined reference to `_Unwind_Resume' /opt/cray/xe-sysroot/4.2.34/usr/lib64/libc.a(ioftell.o):(.eh_frame+0x14b): undefined reference to `__gcc_personality_v0' /opt/cray/xe-sysroot/4.2.34/usr/lib64/libc.a(iogetdelim.o): In function `_IO_acquire_lock_fct': /usr/src/packages/BUILD/glibc-2.11.3/libio/libioP.h:969: undefined reference to `_Unwind_Resume' /opt/cray/xe-sysroot/4.2.34/usr/lib64/libc.a(iogetdelim.o):(.eh_frame+0x14b): undefined reference to `__gcc_personality_v0' /opt/cray/xe-sysroot/4.2.34/usr/lib64/libc.a(ioseekoff.o): In function `_IO_acquire_lock_fct': /usr/src/packages/BUILD/glibc-2.11.3/libio/../libio/libioP.h:969: undefined reference to `_Unwind_Resume' /opt/cray/xe-sysroot/4.2.34/usr/lib64/libc.a(ioseekoff.o):(.eh_frame+0x14b): undefined reference to `__gcc_personality_v0' /opt/cray/xe-sysroot/4.2.34/usr/lib64/libc.a(writev.o): In function `ifree': /usr/src/packages/BUILD/glibc-2.11.3/misc/../sysdeps/posix/writev.c:32: undefined reference to `_Unwind_Resume' /opt/cray/xe-sysroot/4.2.34/usr/lib64/libc.a(writev.o):(.eh_frame+0x13): undefined reference to `__gcc_personality_v0' /opt/cray/xe-sysroot/4.2.34/usr/lib64/libc.a(fseek.o): In function `_IO_acquire_lock_fct': /usr/src/packages/BUILD/glibc-2.11.3/libio/libioP.h:969: undefined reference to `_Unwind_Resume' /opt/cray/xe-sysroot/4.2.34/usr/lib64/libc.a(fseek.o):(.eh_frame+0x14b): undefined reference to `__gcc_personality_v0' /opt/cray/xe-sysroot/4.2.34/usr/lib64/libc.a(ftello.o): In function `_IO_acquire_lock_fct': /usr/src/packages/BUILD/glibc-2.11.3/libio/../libio/libioP.h:969: undefined reference to `_Unwind_Resume' /opt/cray/xe-sysroot/4.2.34/usr/lib64/libc.a(ftello.o):(.eh_frame+0x14b): undefined reference to `__gcc_personality_v0' /usr/bin/ld: link errors found, deleting executable `memcheck-amd64-linux' collect2: error: ld returned 1 exit status -- View this message in context: http://valgrind.10908.n7.nabble.com/building-valgrind-perftools-lite-linking-error-tp49214.html Sent from the Valgrind - Users mailing list archive at Nabble.com. |
|
From: John R. <jr...@Bi...> - 2014-04-07 03:59:13
|
> I'm trying to profile valgrind using perftools-lite and when compiling > the tools I get an undefined reference error. > VEX and coregrind build, but during linking it errs (error is below). > > I think it has do with static linking, the build command in memcheck was: > > ../coregrind/link_tool_exe_linux 0x38000000 cc -Wno-long-long -gdwarf-3 > -gstrict-dwarf -Wwrite-strings -fno-stack-protector -o > memcheck-amd64-linux -m64 -O2 -g -Wall -Wmissing-prototypes -Wshadow > -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations > -Wno-format-zero-length -fno-strict-aliasing -fno-builtin > -fno-omit-frame-pointer -O2 -nodefaultlibs -nostartfiles -u _start > -Wl,--build-id=none -m64 memcheck_amd64_linux-mc_leakcheck.o > memcheck_amd64_linux-mc_malloc_wrappers.o memcheck_amd64_linux-mc_main.o > memcheck_amd64_linux-mc_translate.o memcheck_amd64_linux-mc_machine.o > memcheck_amd64_linux-mc_errors.o ../coregrind/libcoregrind-amd64-linux.a > ../VEX/libvex-amd64-linux.a -lgcc > > Does anyone have any suggestions on how to resolve this? Run the link_tool_exe_linux under strace: strace -f -e trace=execve,file -o strace.out ../coregrind/link_tool_exe_linux ... in order to find out how many levels of execve() are involved, and exactly which files are referenced when. Many of the undefined symbols, such as _Unwind_Resume, are defined in libgcc_s.so.1 or libgcc_eh.so.1. So if you don't see those filenames, or the *.a archive library analogs, then that's the problem. Add them explicitly to the command line. |
|
From: janjust <tja...@un...> - 2014-04-08 03:37:16
|
Hi John, Thanks for the reply. I found that perftools-lite do not support static linking (kinda odd). There are no perf.a files to be linked statically with valgrind; however, perftools should work with static linking. The perftools process is: build your application and retain object files, then use: $pat_build -O apa <executable> This gives a new executable to run. However, I tried instrumenting the nulltool but get: ERROR: Missing required ELF section '.note.link' from the program ../none-amd64-linux I presume this is somehow stripped from none-amd64-linux? Could this line in the makefile have anything to do whit this? 523 # -Wl,--build-id=none is needed when linking tools with a linker that only 524 # knows -Ttext and not -Ttext-segment. Without this flag newer ld versions 525 # (2.20 and later) create a .note.gnu.build-id at the default text segment 526 # address, which of course means the resulting executable 527 # is unusable. So we have to tell ld not to generate that, with 528 # --build-id=none unless the linker supports -Ttext-segment. 529 TOOL_LDFLAGS_COMMON_LINUX = \ 530 -static -nodefaultlibs -nostartfiles -u _start Any ideas? -- View this message in context: http://valgrind.10908.n7.nabble.com/building-valgrind-perftools-lite-linking-error-tp49214p49230.html Sent from the Valgrind - Users mailing list archive at Nabble.com. |
|
From: John R. <jr...@Bi...> - 2014-04-08 04:57:58
|
Hi janjust, > I found that perftools-lite do not support static > linking (kinda odd). > There are no perf.a files to be linked statically with valgrind; however, > perftools should work with static linking. > > The perftools process is: > build your application and retain object files, then use: > $pat_build -O apa <executable> > This gives a new executable to run. > > However, I tried instrumenting the nulltool but get: > ERROR: Missing required ELF section '.note.link' from the program > ../none-amd64-linux It would be good to know whether that complaint is from valgrind, or from perftools, or from the app itself. And "../none-amd64-linux" is a peculiar name for a program; instead that usually designates an execution environment by naming three relevant pieces. In this case "amd64" is the hardware, "linux" is the operating system, and "none" is some aspect that I don't know. > > I presume this is somehow stripped from none-amd64-linux? > > Could this line in the makefile have anything to do whit this? I suppose it could, but the connection is not obvious. Vary the command-line parameters by removing each one individually (keeping the others), and see what complaints you get. Probably the individual results won't run, but we're after hints from any warnings or error messages that might arise. > > 523 # -Wl,--build-id=none is needed when linking tools with a linker that > only > 524 # knows -Ttext and not -Ttext-segment. Without this flag newer ld > versions > 525 # (2.20 and later) create a .note.gnu.build-id at the default text > segment > 526 # address, which of course means the resulting executable > 527 # is unusable. So we have to tell ld not to generate that, with > 528 # --build-id=none unless the linker supports -Ttext-segment. > 529 TOOL_LDFLAGS_COMMON_LINUX = \ > 530 -static -nodefaultlibs -nostartfiles -u _start Run "readelf --sections" on every binary file that contributes [including by transitive closure] to the "final executable", and see where all the ".note.link" sections are. See if any of them disappear before the end. |
|
From: Philippe W. <phi...@sk...> - 2014-04-13 11:37:03
|
On Sun, 2014-04-06 at 19:29 -0700, janjust wrote: > Hi, > I'm trying to profile valgrind using perftools-lite and when compiling > the tools I get an undefined reference error. > VEX and coregrind build, but during linking it errs (error is below). > > I think it has do with static linking, the build command in memcheck was: > > ../coregrind/link_tool_exe_linux 0x38000000 cc -Wno-long-long -gdwarf-3 > -gstrict-dwarf -Wwrite-strings -fno-stack-protector -o > memcheck-amd64-linux -m64 -O2 -g -Wall -Wmissing-prototypes -Wshadow > -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations > -Wno-format-zero-length -fno-strict-aliasing -fno-builtin > -fno-omit-frame-pointer -O2 -nodefaultlibs -nostartfiles -u _start > -Wl,--build-id=none -m64 memcheck_amd64_linux-mc_leakcheck.o > memcheck_amd64_linux-mc_malloc_wrappers.o memcheck_amd64_linux-mc_main.o > memcheck_amd64_linux-mc_translate.o memcheck_amd64_linux-mc_machine.o > memcheck_amd64_linux-mc_errors.o ../coregrind/libcoregrind-amd64-linux.a > ../VEX/libvex-amd64-linux.a -lgcc > > Does anyone have any suggestions on how to resolve this? Valgrind does not use any libs (even does not use glibc), and I guess for a very good reason, as not using any lib has quite some consequences. To my knowledge, 2 techniques are working to profile valgrind: 1. oprofile 2. self-hosting (i.e. running valgrind under a valgrind tool such as callgrind or cachegrind. For more info about self-hosting, search for "Self-hosting" in README_DEVELOPERS Philippe |
|
From: Josef W. <Jos...@gm...> - 2014-04-15 14:17:19
|
Am 13.04.2014 13:37, schrieb Philippe Waroquiers: > On Sun, 2014-04-06 at 19:29 -0700, janjust wrote: >> Hi, >> I'm trying to profile valgrind using perftools-lite and when compiling >> the tools I get an undefined reference error. >> VEX and coregrind build, but during linking it errs (error is below). ... > To my knowledge, 2 techniques are working to profile valgrind: > 1. oprofile > 2. self-hosting (i.e. running valgrind under a valgrind tool such as > callgrind or cachegrind. > For more info about self-hosting, search for "Self-hosting" > in README_DEVELOPERS It also should work with perf, shouldn't it? Josef > > Philippe > > > > ------------------------------------------------------------------------------ > Put Bad Developers to Shame > Dominate Development with Jenkins Continuous Integration > Continuously Automate Build, Test & Deployment > Start a new project now. Try Jenkins in the cloud. > http://p.sf.net/sfu/13600_Cloudbees > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: Philippe W. <phi...@sk...> - 2014-04-15 20:25:32
|
On Mon, 2014-04-14 at 15:38 +0200, Josef Weidendorfer wrote: > Am 13.04.2014 13:37, schrieb Philippe Waroquiers: > > To my knowledge, 2 techniques are working to profile valgrind: > > 1. oprofile > > 2. self-hosting (i.e. running valgrind under a valgrind tool such as > > callgrind or cachegrind. > > For more info about self-hosting, search for "Self-hosting" > > in README_DEVELOPERS > > It also should work with perf, shouldn't it? I guess yes, never tried but I am taking note of this 3rd possibility. Philippe |
Thanks for helping keep SourceForge clean.
X