Re: libbacktrace patch committed: Trace through shared libraries
On Thu, Oct 11, 2012 at 1:44 AM, Rainer Orth wrote: > Ian Lance Taylor writes: > >> On Wed, Oct 10, 2012 at 7:13 AM, Rainer Orth >> wrote: >>> >>> Solaris 10 Update 10 or sufficiently recent linker patches introduced >>> dl_iterate_phdr on S10 as a backport from Solaris 11, but unlike S11, it >>> lives in libdl.so only. The current dl_iterate_phdr check misses that, >>> and given that it's only available in the most recent update, it's >>> probably best to avoid d_i_p on Solaris 10 altogether. >> >> Does this patch fix the problem? > > Yes, works like a charm: Solaris 10/x86 results (both go and libgo) are > back to normal. Thanks, committed with this ChangeLog entry. Ian 2012-10-11 Ian Lance Taylor * configure.ac: Do not use dl_iterate_phdr on Solaris 10. * configure: Rebuild.
Re: libbacktrace patch committed: Trace through shared libraries
Ian Lance Taylor writes: > On Wed, Oct 10, 2012 at 7:13 AM, Rainer Orth > wrote: >> >> Solaris 10 Update 10 or sufficiently recent linker patches introduced >> dl_iterate_phdr on S10 as a backport from Solaris 11, but unlike S11, it >> lives in libdl.so only. The current dl_iterate_phdr check misses that, >> and given that it's only available in the most recent update, it's >> probably best to avoid d_i_p on Solaris 10 altogether. > > Does this patch fix the problem? Yes, works like a charm: Solaris 10/x86 results (both go and libgo) are back to normal. I'm only seeing two failures: The 32-bit net/http test tails (may be transient): --- FAIL: http_test.TestTransportPersistConnLeak (3.53 seconds) :0: goroutine growth: 106 -> 181 -> 125 (delta: 19) :0: too many new goroutines FAIL FAIL: net/http FAIL: runtime/pprof Already reported as PR go/54873. Thanks. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: libbacktrace patch committed: Trace through shared libraries
On Wed, Oct 10, 2012 at 7:13 AM, Rainer Orth wrote: > > Solaris 10 Update 10 or sufficiently recent linker patches introduced > dl_iterate_phdr on S10 as a backport from Solaris 11, but unlike S11, it > lives in libdl.so only. The current dl_iterate_phdr check misses that, > and given that it's only available in the most recent update, it's > probably best to avoid d_i_p on Solaris 10 altogether. Does this patch fix the problem? Ian foo.patch Description: Binary data
Re: libbacktrace patch committed: Trace through shared libraries
Ian Lance Taylor writes: > This patch to libbacktrace adds support for tracing through shared > libraries. The libraries are found by calling dl_iterate_phdr, when it > is available. Unfortunately, this breaks all Go link tests on Solaris 10: output is: Undefined first referenced symbol in file dl_iterate_phdr /var/gcc/gcc-4.8.0-20121010/10-gcc-gas/i386-pc-solaris2.10/./libgo/.libs/libgo.so ld: fatal: symbol referencing errors. No output written to /var/gcc/gcc-4.8.0-20121010/10-gcc-gas/gcc/testsuite/go/array-1.x collect2: error: ld returned 1 exit status FAIL: go.go-torture/execute/array-1.go compilation, -O0 Solaris 10 Update 10 or sufficiently recent linker patches introduced dl_iterate_phdr on S10 as a backport from Solaris 11, but unlike S11, it lives in libdl.so only. The current dl_iterate_phdr check misses that, and given that it's only available in the most recent update, it's probably best to avoid d_i_p on Solaris 10 altogether. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: libbacktrace patch committed: Trace through shared libraries
On Tue, 9 Oct 2012, Ian Lance Taylor wrote:
> It's an incorrect warning from an old version of GCC. Fixed like so.
> Bootstrapped and ran libbacktrace testsuite on
> x86_64-unknown-linux-gnu. Committed to mainline.
Another two in libbackend/elf.c, committed as obvious after
build passed the point-of-failure.
* elf.c (elf_add_syminfo_data): Add casts to avoid warning.
Index: libbacktrace/elf.c
===
--- libbacktrace/elf.c (revision 192306)
+++ libbacktrace/elf.c (working copy)
@@ -410,7 +410,7 @@ elf_add_syminfo_data (struct backtrace_s
{
struct elf_syminfo_data **pp;
- for (pp = (struct elf_syminfo_data **) &state->syminfo_data;
+ for (pp = (struct elf_syminfo_data **) (void *) &state->syminfo_data;
*pp != NULL;
pp = &(*pp)->next)
;
@@ -422,7 +422,7 @@ elf_add_syminfo_data (struct backtrace_s
{
struct elf_syminfo_data **pp;
- pp = (struct elf_syminfo_data **) &state->syminfo_data;
+ pp = (struct elf_syminfo_data **) (void *) &state->syminfo_data;
while (1)
{
brgds, H-P
Re: libbacktrace patch committed: Trace through shared libraries
On Tue, Oct 9, 2012 at 9:28 PM, Hans-Peter Nilsson wrote: > On Tue, 9 Oct 2012, Ian Lance Taylor wrote: >> Patch bootstrapped and ran libbacktrace and Go testsuites on >> x86_64-unknown-linux-gnu. Committed to mainline. > > Trying x86_64 host gcc 4.1.2 (--target=rl78-elf but not the issue) at > r192285: > > /bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H > -I. -I/tmp/rl78b/gcc/libbacktrace -I /tmp/rl78b/gcc/li\ > bbacktrace/../include -I /tmp/rl78b/gcc/libbacktrace/../libgcc > -I ../libgcc -I ../gcc/include -I ../../gcc/include -fu\ > nwind-tables -W -Wall -Wwrite-strings -Wstrict-prototypes > -Wmissing-prototypes -Wold-style-definition -Wmissing-format-\ > attribute -Wcast-qual -Werror -g -O2 -c -o dwarf.lo > /tmp/rl78b/gcc/libbacktrace/dwarf.c > libtool: compile: gcc -DHAVE_CONFIG_H -I. > -I/tmp/rl78b/gcc/libbacktrace -I > /tmp/rl78b/gcc/libbacktrace/../include -I /\ > tmp/rl78b/gcc/libbacktrace/../libgcc -I ../libgcc -I > ../gcc/include -I ../../gcc/include -funwind-tables -W -Wall > -Wwri\ > te-strings -Wstrict-prototypes -Wmissing-prototypes > -Wold-style-definition -Wmissing-format-attribute -Wcast-qual > -Werr\ > or -g -O2 -c /tmp/rl78b/gcc/libbacktrace/dwarf.c -o dwarf.o > cc1: warnings being treated as errors > /tmp/rl78b/gcc/libbacktrace/dwarf.c: In function > 'dwarf_fileline': > /tmp/rl78b/gcc/libbacktrace/dwarf.c:2766: warning: dereferencing > type-punned pointer will break strict-aliasing rules > /tmp/rl78b/gcc/libbacktrace/dwarf.c: In function > 'backtrace_dwarf_add': > /tmp/rl78b/gcc/libbacktrace/dwarf.c:2887: warning: dereferencing > type-punned pointer will break strict-aliasing rules > /tmp/rl78b/gcc/libbacktrace/dwarf.c:2899: warning: dereferencing > type-punned pointer will break strict-aliasing rules > make[3]: *** [dwarf.lo] Error 1 It's an incorrect warning from an old version of GCC. Fixed like so. Bootstrapped and ran libbacktrace testsuite on x86_64-unknown-linux-gnu. Committed to mainline. Ian 2012-10-09 Ian Lance Taylor * dwarf.c (dwarf_fileline): Add cast to avoid warning. (backtrace_dwarf_add): Likewise. foo.patch Description: Binary data
Re: libbacktrace patch committed: Trace through shared libraries
On Tue, 9 Oct 2012, Ian Lance Taylor wrote: > Patch bootstrapped and ran libbacktrace and Go testsuites on > x86_64-unknown-linux-gnu. Committed to mainline. Trying x86_64 host gcc 4.1.2 (--target=rl78-elf but not the issue) at r192285: /bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I/tmp/rl78b/gcc/libbacktrace -I /tmp/rl78b/gcc/li\ bbacktrace/../include -I /tmp/rl78b/gcc/libbacktrace/../libgcc -I ../libgcc -I ../gcc/include -I ../../gcc/include -fu\ nwind-tables -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-\ attribute -Wcast-qual -Werror -g -O2 -c -o dwarf.lo /tmp/rl78b/gcc/libbacktrace/dwarf.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I/tmp/rl78b/gcc/libbacktrace -I /tmp/rl78b/gcc/libbacktrace/../include -I /\ tmp/rl78b/gcc/libbacktrace/../libgcc -I ../libgcc -I ../gcc/include -I ../../gcc/include -funwind-tables -W -Wall -Wwri\ te-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -Wcast-qual -Werr\ or -g -O2 -c /tmp/rl78b/gcc/libbacktrace/dwarf.c -o dwarf.o cc1: warnings being treated as errors /tmp/rl78b/gcc/libbacktrace/dwarf.c: In function 'dwarf_fileline': /tmp/rl78b/gcc/libbacktrace/dwarf.c:2766: warning: dereferencing type-punned pointer will break strict-aliasing rules /tmp/rl78b/gcc/libbacktrace/dwarf.c: In function 'backtrace_dwarf_add': /tmp/rl78b/gcc/libbacktrace/dwarf.c:2887: warning: dereferencing type-punned pointer will break strict-aliasing rules /tmp/rl78b/gcc/libbacktrace/dwarf.c:2899: warning: dereferencing type-punned pointer will break strict-aliasing rules make[3]: *** [dwarf.lo] Error 1 brgds, H-P
Re: libbacktrace patch committed: Trace through shared libraries
On Tue, Oct 09, 2012 at 01:43:06PM -0700, Ian Lance Taylor wrote: > On Tue, Oct 9, 2012 at 11:32 AM, Basile Starynkevitch > wrote: > > > > You could provide an extra API to register dlopen & dlclose to > > libbacktrace, if that helps you > > (of course, I would prefer avoiding that) > > I would prefer avoiding that as well. > > Calling dl_iterate_phdr can tell libbacktrace reliably the set of > shared libraries that are currently loaded. The trick is knowing when > to call it. It may simply be OK to call it every time we look up a PC > value, in which case we can look at the dlpi_adds and dlpi_subs field. > I'm not sure. See unwind-dw2-fde-dip.c how it uses it. I think for all PC queries from one backtrace you should get away with using a cache of last looked up library even without calling dl_iterate_phdr. PCs in the backtrace can't go away from under you in a properly written application (but only those, not others). In between different backtrace calls you need to call dl_iterate_phdr (primarily to lock the ld.so lock and prevent dlopen/dlclose from other threads), but can use a cache there and use dlpi_adds/dlpi_subs to find out when to invalidate the cache. Jakub
Re: libbacktrace patch committed: Trace through shared libraries
On Tue, Oct 9, 2012 at 11:32 AM, Basile Starynkevitch wrote: > > You could provide an extra API to register dlopen & dlclose to libbacktrace, > if that helps you > (of course, I would prefer avoiding that) I would prefer avoiding that as well. Calling dl_iterate_phdr can tell libbacktrace reliably the set of shared libraries that are currently loaded. The trick is knowing when to call it. It may simply be OK to call it every time we look up a PC value, in which case we can look at the dlpi_adds and dlpi_subs field. I'm not sure. Ian
Re: libbacktrace patch committed: Trace through shared libraries
On Tue, Oct 09, 2012 at 11:20:48AM -0700, Ian Lance Taylor wrote:
> This patch to libbacktrace adds support for tracing through shared
> libraries. The libraries are found by calling dl_iterate_phdr, when it
> is available.
This functionality is definitely useful for meta-plugins like MELT
(since melt.so is dlopen-ing things)
>
> This patch has some preliminary support for tracing through libaries
> opened via dlopen, but there is no code for actually finding such
> libraries.
Perhaps you might use dladdr, on the few systems (notably GNU/Libc on Linux)
which have it?
>From man dlsym output:
int dladdr(void *addr, Dl_info *info);
The function dladdr() takes a function pointer and tries to resolve
name and file where it is located. Information is stored in the
Dl_info structure:
typedef struct {
const char *dli_fname; /* Pathname of shared object that
contains address */
void *dli_fbase; /* Address at which shared object
is loaded */
const char *dli_sname; /* Name of nearest symbol with address
lower than addr */
void *dli_saddr; /* Exact address of symbol named
in dli_sname */
} Dl_info;
If no symbol matching addr could be found, then dli_sname and dli_saddr
are set to NULL.
dladdr() returns 0 on error, and nonzero on success.
Or maybe I misunderstood libbacktrace and my comment is irrelevant. If it is
the case, sorry for the noise.
You could provide an extra API to register dlopen & dlclose to libbacktrace, if
that helps you
(of course, I would prefer avoiding that)
Cheers
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
