Re: dlopen() and -pg
On Tue, Nov 26, 2019 at 06:14:37PM +0100, Joerg Sonnenberger wrote: > devel/gperftools? thanks. From first tests, it seems to have trouble building call graphs, and decoding library function names, but I'll keep experimenting. Maybe it'll give something usefull. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: dlopen() and -pg
On Tue, Nov 26, 2019 at 04:05:22PM +0100, Manuel Bouyer wrote: > On Tue, Nov 26, 2019 at 03:24:20PM +0100, Joerg Sonnenberger wrote: > > On Tue, Nov 26, 2019 at 03:18:03PM +0100, Manuel Bouyer wrote: > > > trying to profile a c++ program which uses dlopen and pthreads (opencpn, > > > FWIW), > > > > I'm not surprised at all. -pg will only work reliable with -static. > > And I can't link statically, as it depends on libraries that are only > available > as .so. > > Is there some other profiling tools working on NetBSD ? devel/gperftools? Joerg
Re: dlopen() and -pg
On Tue, Nov 26, 2019 at 03:24:20PM +0100, Joerg Sonnenberger wrote: > On Tue, Nov 26, 2019 at 03:18:03PM +0100, Manuel Bouyer wrote: > > trying to profile a c++ program which uses dlopen and pthreads (opencpn, > > FWIW), > > I'm not surprised at all. -pg will only work reliable with -static. And I can't link statically, as it depends on libraries that are only available as .so. Is there some other profiling tools working on NetBSD ? -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: dlopen() and -pg
On Tue, Nov 26, 2019 at 03:18:03PM +0100, Manuel Bouyer wrote: > trying to profile a c++ program which uses dlopen and pthreads (opencpn, > FWIW), I'm not surprised at all. -pg will only work reliable with -static. Joerg
dlopen() and -pg
Hello, trying to profile a c++ program which uses dlopen and pthreads (opencpn, FWIW), I get a core dump: Program received signal SIGSEGV, Segmentation fault. 0x006fb040 in dl_iterate_phdr () (gdb) where #0 0x006fb040 in dl_iterate_phdr () #1 0x006fd7d0 in __libc_static_tls_setup () #2 0x007d5d20 in _libc_init () #3 0x7bb33844 in _rtld_call_function_void (obj=0x6d42c000, addr=8215716) at /usr/src/libexec/ld.elf_so/rtld.h:488 #4 _rtld_call_initfini_function (obj=0x6d42c000, mask=, func=8215716) at /usr/src/libexec/ld.elf_so/rtld.c:143 #5 _rtld_call_init_function (cur_objgen=, mask=, obj=0x6d42c000) at /usr/src/libexec/ld.elf_so/rtld.c:258 #6 _rtld_call_init_functions (mask=mask@entry=0x7ffd4480) at /usr/src/libexec/ld.elf_so/rtld.c:316 #7 0x7bb3442c in _rtld (sp=, relocbase=) at /usr/src/libexec/ld.elf_so/rtld.c:782 #8 0x7bb305b4 in _rtld_start () from /usr/libexec/ld.elf_so #9 0x7bb305b4 in _rtld_start () from /usr/libexec/ld.elf_so #10 0x7bb305b4 in _rtld_start () from /usr/libexec/ld.elf_so #11 0x7bb305b4 in _rtld_start () from /usr/libexec/ld.elf_so #12 0x7bb305b4 in _rtld_start () from /usr/libexec/ld.elf_so #13 0x7bb305b4 in _rtld_start () from /usr/libexec/ld.elf_so #14 0x7bb305b4 in _rtld_start () from /usr/libexec/ld.elf_so #15 0x7bb305b4 in _rtld_start () from /usr/libexec/ld.elf_so [...] (here it seems to be looping on _rtld_start(), but it may be a debugger issue). This is on 9.0_BETA; the above stack trace is on earmv7hf but I get the same on x86_64. A hello world c++ program works as expected Any idea ? -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
