Re: Backtrace library [1/3]
On 12-09-19 06:58 PM, Ian Lance Taylor wrote: Thanks for the additional info. I have committed this patch, which should fix the problem. Bootstrapped and ran libbacktrace tests on x86_64-unknown-linux-gnu. Thanks Ian. This patch fixes the issue. Regards, Ryan Mansfield 2012-09-19 Ian Lance Taylor * configure.ac: Only use GCC_CHECK_UNWIND_GETIPINFO when compiled as a target library. * configure: Rebuild.
Re: Backtrace library [1/3]
On Wed, Sep 19, 2012 at 3:31 PM, Ryan Mansfield wrote: > $ head config.log > This file contains any messages produced by compilers while > running configure, to aid debugging if configure makes a mistake. > > It was created by configure, which was > generated by GNU Autoconf 2.64. Invocation command line was > > $ ../configure --disable-bootstrap --enable-languages=c++ > > ## - ## > ## Platform. ## > > > >> Please check HAVE_GETIPINFO in libbacktrace/config.h. I assume it is 1. > > > Yep, it's 1. > > $ grep HAVE_GETIPINFO config.h > #define HAVE_GETIPINFO 1 > > >> It looks like you may be doing some sort of Canadian Cross build. >> What version of GCC is i686-unknown-linux-gnu-gcc? Does that version >> of gcc declare _Unwind_GetIPInfo in its unwind.h? Does it provide >> _Unwind_GetIPInfo in its libgcc? > > > I'm using gcc 4.1 on this machine. No, it doesn't have it in the unwind.h or > libgcc. Thanks for the additional info. I have committed this patch, which should fix the problem. Bootstrapped and ran libbacktrace tests on x86_64-unknown-linux-gnu. Ian 2012-09-19 Ian Lance Taylor * configure.ac: Only use GCC_CHECK_UNWIND_GETIPINFO when compiled as a target library. * configure: Rebuild. foo.patch Description: Binary data
Re: Backtrace library [1/3]
On 12-09-19 06:17 PM, Ian Lance Taylor wrote: On Wed, Sep 19, 2012 at 1:56 PM, Ryan Mansfield wrote: I'm hitting the following build issue /bin/sh ./libtool --tag=CC --mode=compile i686-unknown-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../../libbacktrace -I ../../libbacktrace/../include -I ../../libbacktrace/../libgcc -I ../libgcc -I ../gcc/include -I ../../gcc/include -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -Wcast-qual -Werror -g -O2 -MT backtrace.lo -MD -MP -MF .deps/backtrace.Tpo -c -o backtrace.lo ../../libbacktrace/backtrace.c libtool: compile: i686-unknown-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../../libbacktrace -I ../../libbacktrace/../include -I ../../libbacktrace/../libgcc -I ../libgcc -I ../gcc/include -I ../../gcc/include -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -Wcast-qual -Werror -g -O2 -MT backtrace.lo -MD -MP -MF .deps/backtrace.Tpo -c ../../libbacktrace/backtrace.c -o backtrace.o cc1: warnings being treated as errors ../../libbacktrace/backtrace.c: In function 'unwind': ../../libbacktrace/backtrace.c:69: warning: implicit declaration of function '_Unwind_GetIPInfo' make[3]: *** [backtrace.lo] Error 1 Don't omit the details: How precisely did you run configure? In what directory is this error occurring? $ head config.log This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by configure, which was generated by GNU Autoconf 2.64. Invocation command line was $ ../configure --disable-bootstrap --enable-languages=c++ ## - ## ## Platform. ## Please check HAVE_GETIPINFO in libbacktrace/config.h. I assume it is 1. Yep, it's 1. $ grep HAVE_GETIPINFO config.h #define HAVE_GETIPINFO 1 It looks like you may be doing some sort of Canadian Cross build. What version of GCC is i686-unknown-linux-gnu-gcc? Does that version of gcc declare _Unwind_GetIPInfo in its unwind.h? Does it provide _Unwind_GetIPInfo in its libgcc? I'm using gcc 4.1 on this machine. No, it doesn't have it in the unwind.h or libgcc. Regards, Ryan Mansfield
Re: Backtrace library [1/3]
On Wed, Sep 19, 2012 at 1:56 PM, Ryan Mansfield wrote: > > I'm hitting the following build issue > > /bin/sh ./libtool --tag=CC --mode=compile i686-unknown-linux-gnu-gcc > -DHAVE_CONFIG_H -I. -I../../libbacktrace -I ../../libbacktrace/../include > -I ../../libbacktrace/../libgcc -I ../libgcc -I ../gcc/include -I > ../../gcc/include -W -Wall -Wwrite-strings -Wstrict-prototypes > -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute > -Wcast-qual -Werror -g -O2 -MT backtrace.lo -MD -MP -MF .deps/backtrace.Tpo > -c -o backtrace.lo ../../libbacktrace/backtrace.c > libtool: compile: i686-unknown-linux-gnu-gcc -DHAVE_CONFIG_H -I. > -I../../libbacktrace -I ../../libbacktrace/../include -I > ../../libbacktrace/../libgcc -I ../libgcc -I ../gcc/include -I > ../../gcc/include -W -Wall -Wwrite-strings -Wstrict-prototypes > -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute > -Wcast-qual -Werror -g -O2 -MT backtrace.lo -MD -MP -MF .deps/backtrace.Tpo > -c ../../libbacktrace/backtrace.c -o backtrace.o > > cc1: warnings being treated as errors > ../../libbacktrace/backtrace.c: In function 'unwind': > ../../libbacktrace/backtrace.c:69: warning: implicit declaration of function > '_Unwind_GetIPInfo' > make[3]: *** [backtrace.lo] Error 1 Don't omit the details: How precisely did you run configure? In what directory is this error occurring? Please check HAVE_GETIPINFO in libbacktrace/config.h. I assume it is 1. It looks like you may be doing some sort of Canadian Cross build. What version of GCC is i686-unknown-linux-gnu-gcc? Does that version of gcc declare _Unwind_GetIPInfo in its unwind.h? Does it provide _Unwind_GetIPInfo in its libgcc? Ian
Re: Backtrace library [1/3]
On 12-09-17 12:39 PM, Ian Lance Taylor wrote: On Thu, Sep 13, 2012 at 1:00 PM, Diego Novillo wrote: On 2012-09-11 18:53 , Ian Lance Taylor wrote: 2012-09-11 Ian Lance Taylor * Initial implementation. OK. Thanks for all the reviews. I have committed the libbacktrace library to trunk. I will follow up with a patch to actually use it. Please let me know about any build problems. I'm hitting the following build issue /bin/sh ./libtool --tag=CC --mode=compile i686-unknown-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../../libbacktrace -I ../../libbacktrace/../include -I ../../libbacktrace/../libgcc -I ../libgcc -I ../gcc/include -I ../../gcc/include -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -Wcast-qual -Werror -g -O2 -MT backtrace.lo -MD -MP -MF .deps/backtrace.Tpo -c -o backtrace.lo ../../libbacktrace/backtrace.c libtool: compile: i686-unknown-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../../libbacktrace -I ../../libbacktrace/../include -I ../../libbacktrace/../libgcc -I ../libgcc -I ../gcc/include -I ../../gcc/include -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -Wcast-qual -Werror -g -O2 -MT backtrace.lo -MD -MP -MF .deps/backtrace.Tpo -c ../../libbacktrace/backtrace.c -o backtrace.o cc1: warnings being treated as errors ../../libbacktrace/backtrace.c: In function 'unwind': ../../libbacktrace/backtrace.c:69: warning: implicit declaration of function '_Unwind_GetIPInfo' make[3]: *** [backtrace.lo] Error 1 Regards, Ryan Mansfield
Re: Backtrace library [1/3]
It turns out "make bootstrap" work now, but "make install" is still broken on i386-unknown-freebsd10.0: libtool: compile: gcc -DHAVE_CONFIG_H -I. -I/scratch2/tmp/gerald/gcc-HEAD/libbacktrace -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -Wcast-qual -Werror -I /scratch2/tmp/gerald/gcc-HEAD/libbacktrace/../include -I ../libgcc -g -O2 -MT backtrace.lo -MD -MP -MF .deps/backtrace.Tpo -c /scratch2/tmp/gerald/gcc-HEAD/libbacktrace/backtrace.c -o backtrace.o /scratch2/tmp/gerald/gcc-HEAD/libbacktrace/backtrace.c:35:20: error: unwind.h: No such file or directory /scratch2/tmp/gerald/gcc-HEAD/libbacktrace/backtrace.c:62: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'unwind' cc1: warnings being treated as errors /scratch2/tmp/gerald/gcc-HEAD/libbacktrace/backtrace.c: In function 'backtrace_full': /scratch2/tmp/gerald/gcc-HEAD/libbacktrace/backtrace.c:106: warning: implicit declaration of function '_Unwind_Backtrace' /scratch2/tmp/gerald/gcc-HEAD/libbacktrace/backtrace.c:106: error: 'unwind' undeclared (first use in this function) /scratch2/tmp/gerald/gcc-HEAD/libbacktrace/backtrace.c:106: error: (Each undeclared identifier is reported only once /scratch2/tmp/gerald/gcc-HEAD/libbacktrace/backtrace.c:106: error: for each function it appears in.) gmake[2]: *** [backtrace.lo] Error 1 gmake[2]: Leaving directory `/scratch2/tmp/gerald/OBJ-0919-0258/libbacktrace' gmake[1]: *** [install-libbacktrace] Error 2 gmake[1]: Leaving directory `/scratch2/tmp/gerald/OBJ-0919-0258' gmake: *** [install] Error 2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54623 The line in question reads #include "unwind.h" yet this is nowhere in the source tree, though it's in the build tree at $BUILD/./gcc/include/unwind.h and $BUILD./i386-unknown-freebsd10.0/libgcc/unwind.h . Gerald
Re: Backtrace library [1/3]
On Mon, 17 Sep 2012, Ian Lance Taylor wrote: > While this should be fixed now, note that it should only arise if > i386-unknown-freebsd10.0 does not use ELF. If this is an ELF based > system, then we need to discover why it was not recognized as such. > What is the output of > > awk -f SRCDIR/libbacktrace/filetype.awk foo.o > > for some ELF foo.o file? Thanks for addressing the other half of the bootstrap failure, Ian. You are right, FreeBSD definitely is an ELF system and % awk -f $GCC_SOURCE/libbacktrace/filetype.awk foo.o gives me elf32 on i386-unknown-freebsd10.0. Gerald
Re: Backtrace library [1/3]
On Mon, Sep 17, 2012 at 2:00 PM, Gerald Pfeifer wrote: > On Mon, 17 Sep 2012, Ian Lance Taylor wrote: >> Please let me know about any build problems. > > i386-unknown-freebsd10.0 now fails as follows. Others presumably > have not run into this since "This source file is compiled if the > unwind library is not available". While this should be fixed now, note that it should only arise if i386-unknown-freebsd10.0 does not use ELF. If this is an ELF based system, then we need to discover why it was not recognized as such. What is the output of awk -f SRCDIR/libbacktrace/filetype.awk foo.o for some ELF foo.o file? Ian
Re: Backtrace library [1/3]
On Mon, Sep 17, 2012 at 2:00 PM, Gerald Pfeifer wrote: > On Mon, 17 Sep 2012, Ian Lance Taylor wrote: >> Please let me know about any build problems. > > i386-unknown-freebsd10.0 now fails as follows. Others presumably > have not run into this since "This source file is compiled if the > unwind library is not available". > > /scratch2/tmp/gerald/gcc-HEAD/libbacktrace/nounwind.c:48: warning: no > previous prototype for 'backtrace' > /scratch2/tmp/gerald/gcc-HEAD/libbacktrace/nounwind.c:59: error: conflicting > types for 'backtrace_simple' > /scratch2/tmp/gerald/gcc-HEAD/libbacktrace/backtrace.h:130: error: previous > declaration of 'backtrace_simple' was here > gmake[4]: *** [nounwind.lo] Error 1 > gmake[4]: Leaving directory > `/scratch2/tmp/gerald/OBJ-0917-1906/libbacktrace' > gmake[3]: *** [all] Error 2 > gmake[3]: Leaving directory > `/scratch2/tmp/gerald/OBJ-0917-1906/libbacktrace' > gmake[2]: *** [all-stage1-libbacktrace] Error 2 > gmake[2]: Leaving directory `/scratch2/tmp/gerald/OBJ-0917-1906' > gmake[1]: *** [stage1-bubble] Error 2 > gmake[1]: Leaving directory `/scratch2/tmp/gerald/OBJ-0917-1906' > gmake: *** [bootstrap-lean] Error 2 > > > Tracked as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54611 . > > > There are two different issues breaking the build here. > > The following patch, which I committed as obvious, addresses the second. > Tested by ensuring the bootstrap on this platform is now only breaking > due to the first item. Sorry about that. Fixed like so. Committed to mainline. Ian 2012-09-17 Ian Lance Taylor PR bootstrap/54611 * nounwind.c (backtrace_full): Rename from backtrace. Add state parameter. foo.patch Description: Binary data
Re: Backtrace library [1/3]
On Mon, 17 Sep 2012, Ian Lance Taylor wrote: > Please let me know about any build problems. i386-unknown-freebsd10.0 now fails as follows. Others presumably have not run into this since "This source file is compiled if the unwind library is not available". /scratch2/tmp/gerald/gcc-HEAD/libbacktrace/nounwind.c:48: warning: no previous prototype for 'backtrace' /scratch2/tmp/gerald/gcc-HEAD/libbacktrace/nounwind.c:59: error: conflicting types for 'backtrace_simple' /scratch2/tmp/gerald/gcc-HEAD/libbacktrace/backtrace.h:130: error: previous declaration of 'backtrace_simple' was here gmake[4]: *** [nounwind.lo] Error 1 gmake[4]: Leaving directory `/scratch2/tmp/gerald/OBJ-0917-1906/libbacktrace' gmake[3]: *** [all] Error 2 gmake[3]: Leaving directory `/scratch2/tmp/gerald/OBJ-0917-1906/libbacktrace' gmake[2]: *** [all-stage1-libbacktrace] Error 2 gmake[2]: Leaving directory `/scratch2/tmp/gerald/OBJ-0917-1906' gmake[1]: *** [stage1-bubble] Error 2 gmake[1]: Leaving directory `/scratch2/tmp/gerald/OBJ-0917-1906' gmake: *** [bootstrap-lean] Error 2 Tracked as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54611 . There are two different issues breaking the build here. The following patch, which I committed as obvious, addresses the second. Tested by ensuring the bootstrap on this platform is now only breaking due to the first item. 2012-09-17 Gerald Pfeifer PR bootstrap/54611 * nounwind.c (backtrace_simple): Add state parameter. Index: nounwind.c === --- nounwind.c (revision 191404) +++ nounwind.c (working copy) @@ -53,7 +53,8 @@ } int -backtrace_simple (int skip ATTRIBUTE_UNUSED, +backtrace_simple (struct backtrace_state *state ATTRIBUTE_UNUSED, + int skip ATTRIBUTE_UNUSED, backtrace_simple_callback callback ATTRIBUTE_UNUSED, backtrace_error_callback error_callback, void *data) { I'm running out of time now, but will check again later today or tomorrow for the other item (hoping it'll been magically gone ;-). Gerald
Re: Backtrace library [1/3]
On Thu, Sep 13, 2012 at 1:00 PM, Diego Novillo wrote: > On 2012-09-11 18:53 , Ian Lance Taylor wrote: > >> 2012-09-11 Ian Lance Taylor >> >> * Initial implementation. > > OK. Thanks for all the reviews. I have committed the libbacktrace library to trunk. I will follow up with a patch to actually use it. Please let me know about any build problems. Ian
Re: Backtrace library [1/3]
On 2012-09-11 18:53 , Ian Lance Taylor wrote: 2012-09-11 Ian Lance Taylor * Initial implementation. OK. Diego.
Re: Backtrace library [1/3]
On Wed, Sep 12, 2012 at 2:04 PM, Joseph S. Myers wrote: > On Wed, 12 Sep 2012, Ian Lance Taylor wrote: > >> On Wed, Sep 12, 2012 at 9:23 AM, Joseph S. Myers >> wrote: >> > On Tue, 11 Sep 2012, Ian Lance Taylor wrote: >> > >> >> The configury is fairly standard. Note that libbacktrace is built as >> >> both a host library (to link into the compilers) and as a target library >> >> (to link into libgo and possibly other libraries). >> > >> > Under what circumstances will the library be built for the target - only >> > if a relevant language such as Go is being built, or unconditionally? >> >> My intent is to only build it when something needs it, e.g., libgo. I >> don't know if I've expressed that intent correctly. > > I think that if a library is listed in target_libs in config-lang.in for > at least one language, and if all languages with it so listed are > disabled, then that library will be disabled - but if no languages list it > in config-lang.in, it will be enabled by default. Looks right. If libbacktrace is approved and committed, I will included this patch to gcc/go/config-lang.in. I tested that it indeed causes libbacktrace to be built only for the host, not for the target, when not building Go. Ian Index: gcc/go/config-lang.in === --- gcc/go/config-lang.in (revision 191171) +++ gcc/go/config-lang.in (working copy) @@ -28,7 +28,7 @@ language="go" compilers="go1\$(exeext)" -target_libs="target-libgo target-libffi" +target_libs="target-libgo target-libffi target-libbacktrace" # The Go frontend is written in C++, so we need to build the C++ # compiler during stage 1.
Re: Backtrace library [1/3]
On Wed, 12 Sep 2012, Ian Lance Taylor wrote: > On Wed, Sep 12, 2012 at 9:23 AM, Joseph S. Myers > wrote: > > On Tue, 11 Sep 2012, Ian Lance Taylor wrote: > > > >> The configury is fairly standard. Note that libbacktrace is built as > >> both a host library (to link into the compilers) and as a target library > >> (to link into libgo and possibly other libraries). > > > > Under what circumstances will the library be built for the target - only > > if a relevant language such as Go is being built, or unconditionally? > > My intent is to only build it when something needs it, e.g., libgo. I > don't know if I've expressed that intent correctly. I think that if a library is listed in target_libs in config-lang.in for at least one language, and if all languages with it so listed are disabled, then that library will be disabled - but if no languages list it in config-lang.in, it will be enabled by default. -- Joseph S. Myers jos...@codesourcery.com
Re: Backtrace library [1/3]
On Wed, Sep 12, 2012 at 10:31 AM, Lawrence Crowl wrote: > > How about typing it as a pointer to an incomplete struct? > > extern void *backtrace_create_state (... > > becomes, e.g., > > struct backtrace_state; > extern backtrace_state *backtrace_create_state (... Yeah, that is probably the way to do it. I made that change. I won't bother to send around the patches again. Ian
Re: Backtrace library [1/3]
On Wed, Sep 12, 2012 at 9:23 AM, Joseph S. Myers wrote: > On Tue, 11 Sep 2012, Ian Lance Taylor wrote: > >> The configury is fairly standard. Note that libbacktrace is built as >> both a host library (to link into the compilers) and as a target library >> (to link into libgo and possibly other libraries). > > Under what circumstances will the library be built for the target - only > if a relevant language such as Go is being built, or unconditionally? My intent is to only build it when something needs it, e.g., libgo. I don't know if I've expressed that intent correctly. > If built unconditionally, will the library build OK for the target in > situations where no target headers are yet available? (For such builds of > compilers used to bootstrap libc it would be usual to use various > --disable- options to disable libraries not needed to build libc, and to > use --enable-languages=c, but if this library is used on the host side by > the compiler then the generic --disable-libbacktrace might not suffice > since that would disable the host copy, required by the compiler itself, > as well as the target copy.) The library does currently assume that a few header files are available, so building it would presumably break in this scenario. We could introduce --disable-target-libbacktrace easily enough. Ian
Re: Backtrace library [1/3]
On 9/12/12, Ian Lance Taylor wrote: > On Sep 11, 2012 Lawrence Crowl wrote: > > On 9/11/12, Ian Lance Taylor wrote: > > > This patch is the interface to and configury of libbacktrace. > > > I've separated these out as the parts of libbacktrace that > > > require the most review. The interface to libbacktrace is in > > > the file backtrace.h. This is what callers will use. The file > > > backtrace-supported.h is also available so that programs can > > > see whether calling the backtrace library will work at all. > > > > The interface relies on global data in the library. Wouldn't it > > be better to expose the state as an additional parameter to > > enable concurrent access by different threads? That parameter > > could then be modeled as 'this' parameter, addressing Gaby's > > suggesting. > > I went ahead and added a state parameter to the interface. > I've attached the updated patch. How about typing it as a pointer to an incomplete struct? extern void *backtrace_create_state (... becomes, e.g., struct backtrace_state; extern backtrace_state *backtrace_create_state (... -- Lawrence Crowl
Re: Backtrace library [1/3]
On 09/12/2012 01:08 AM, Ian Lance Taylor wrote: The interface is somewhat constrained in that, on systems that support anonymous mmap, it does not call malloc. That makes it possible to do a symbolic backtrace from a signal handler. It would also make it possible to have a traceback of a segmentation fault caused by corruption of the malloc arena ... -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
Re: Backtrace library [1/3]
On Tue, 11 Sep 2012, Ian Lance Taylor wrote: > The configury is fairly standard. Note that libbacktrace is built as > both a host library (to link into the compilers) and as a target library > (to link into libgo and possibly other libraries). Under what circumstances will the library be built for the target - only if a relevant language such as Go is being built, or unconditionally? If built unconditionally, will the library build OK for the target in situations where no target headers are yet available? (For such builds of compilers used to bootstrap libc it would be usual to use various --disable- options to disable libraries not needed to build libc, and to use --enable-languages=c, but if this library is used on the host side by the compiler then the generic --disable-libbacktrace might not suffice since that would disable the host copy, required by the compiler itself, as well as the target copy.) -- Joseph S. Myers jos...@codesourcery.com
Re: Backtrace library [1/3]
On Tue, Sep 11, 2012 at 4:36 PM, Lawrence Crowl wrote: > On 9/11/12, Ian Lance Taylor wrote: >> This patch is the interface to and configury of libbacktrace. >> I've separated these out as the parts of libbacktrace that >> require the most review. The interface to libbacktrace is in >> the file backtrace.h. This is what callers will use. The file >> backtrace-supported.h is also available so that programs can see >> whether calling the backtrace library will work at all. > > The interface relies on global data in the library. Wouldn't it > be better to expose the state as an additional parameter to enable > concurrent access by different threads? That parameter could then > be modeled as 'this' parameter, addressing Gaby's suggesting. I went ahead and added a state parameter to the interface. I've attached the updated patch. Ian foo1.patch Description: Binary data
Re: Backtrace library [1/3]
On Tue, Sep 11, 2012 at 11:49 PM, Ian Lance Taylor wrote: > On Tue, Sep 11, 2012 at 9:36 PM, Chris Lattner wrote: >> >> On Sep 11, 2012, at 4:24 PM, Ian Lance Taylor wrote: >> >>> On Tue, Sep 11, 2012 at 4:07 PM, Chris Lattner wrote: FYI, "backtrace" is a well-known function provide by glibc (and other libc's). It might be best to pick another name. >>> >>> Good point. Thanks. I renamed it to backtrace_full. I've included >>> the updated backtrace.h here. The other changes are mechanical. >> >> What do you think of (poor man's) namespacification? You could prefix >> symbols with "libbacktrace_", which I think is much less likely to conflict, >> and be much more clear to clients. > > Right now they all begin with "backtrace_". That is a good choice for a C interface. I don't think it needs to be longer. -- Gaby
Re: Backtrace library [1/3]
On Tue, Sep 11, 2012 at 9:36 PM, Chris Lattner wrote: > > On Sep 11, 2012, at 4:24 PM, Ian Lance Taylor wrote: > >> On Tue, Sep 11, 2012 at 4:07 PM, Chris Lattner wrote: >>> >>> FYI, "backtrace" is a well-known function provide by glibc (and other >>> libc's). It might be best to pick another name. >> >> Good point. Thanks. I renamed it to backtrace_full. I've included >> the updated backtrace.h here. The other changes are mechanical. > > What do you think of (poor man's) namespacification? You could prefix > symbols with "libbacktrace_", which I think is much less likely to conflict, > and be much more clear to clients. Right now they all begin with "backtrace_". Any other opinions on whether "libbacktrace_" is better than "backtrace_"? Ian
Re: Backtrace library [1/3]
On Sep 11, 2012, at 4:24 PM, Ian Lance Taylor wrote: > On Tue, Sep 11, 2012 at 4:07 PM, Chris Lattner wrote: >> >> FYI, "backtrace" is a well-known function provide by glibc (and other >> libc's). It might be best to pick another name. > > Good point. Thanks. I renamed it to backtrace_full. I've included > the updated backtrace.h here. The other changes are mechanical. What do you think of (poor man's) namespacification? You could prefix symbols with "libbacktrace_", which I think is much less likely to conflict, and be much more clear to clients. -Chris
Re: Backtrace library [1/3]
On Tue, Sep 11, 2012 at 4:36 PM, Lawrence Crowl wrote: > On 9/11/12, Ian Lance Taylor wrote: >> This patch is the interface to and configury of libbacktrace. >> I've separated these out as the parts of libbacktrace that >> require the most review. The interface to libbacktrace is in >> the file backtrace.h. This is what callers will use. The file >> backtrace-supported.h is also available so that programs can see >> whether calling the backtrace library will work at all. > > The interface relies on global data in the library. Wouldn't it > be better to expose the state as an additional parameter to enable > concurrent access by different threads? That parameter could then > be modeled as 'this' parameter, addressing Gaby's suggesting. To be clear, the library does support concurrent access by different threads. It uses locks internally. And it would have to use internal locks even if I adopt your suggestion, because it would not be reasonable to require each separate thread to independently read and parse the debug info. That said, it's a good idea, and I'll see if it makes sense. Ian
Re: Backtrace library [1/3]
On 9/11/12, Ian Lance Taylor wrote: > This patch is the interface to and configury of libbacktrace. > I've separated these out as the parts of libbacktrace that > require the most review. The interface to libbacktrace is in > the file backtrace.h. This is what callers will use. The file > backtrace-supported.h is also available so that programs can see > whether calling the backtrace library will work at all. The interface relies on global data in the library. Wouldn't it be better to expose the state as an additional parameter to enable concurrent access by different threads? That parameter could then be modeled as 'this' parameter, addressing Gaby's suggesting. -- Lawrence Crowl
Re: Backtrace library [1/3]
On Tue, Sep 11, 2012 at 4:07 PM, Chris Lattner wrote: > > FYI, "backtrace" is a well-known function provide by glibc (and other > libc's). It might be best to pick another name. Good point. Thanks. I renamed it to backtrace_full. I've included the updated backtrace.h here. The other changes are mechanical. Ian /* backtrace.h -- Public header file for stack backtrace library. Copyright (C) 2012 Free Software Foundation, Inc. Written by Ian Lance Taylor, Google. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: (1) Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. (2) Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. (3) The name of the author may not be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. */ #ifndef BACKTRACE_H #define BACKTRACE_H #include #include #include #ifdef __cplusplus extern "C" { #endif /* The backtrace code needs to open the executable file in order to find the debug info. On systems that do not support /proc/self/exe, the program using the backtrace library needs to tell the backtrace library the name of the executable to open. It does so by calling backtrace_set_executable_name. The FILENAME argument must point to a permanent buffer. */ extern void backtrace_set_executable_name (const char *filename); /* The type of the callback argument to the backtrace_full function. DATA is the argument passed to backtrace_full. PC is the program counter. FILENAME is the name of the file containing PC, or NULL if not available. LINENO is the line number in FILENAME containing PC, or 0 if not available. FUNCTION is the name of the function containing PC, or NULL if not available. This should return 0 to continuing tracing. The FILENAME and FUNCTION buffers may become invalid after this function returns. */ typedef int (*backtrace_full_callback) (void *data, uintptr_t pc, const char *filename, int lineno, const char *function); /* The type of the error callback argument to backtrace functions. This function, if not NULL, will be called for certain error cases. The DATA argument is passed to the function that calls this one. The MSG argument is an error message. The ERRNUM argument, if greater than 0, holds an errno value. The MSG buffer may become invalid after this function returns. As a special case, the ERRNUM argument will be passed as -1 if no debug info can be found for the executable, but the function requires debug info (e.g., backtrace_full, backtrace_pcinfo). The MSG in this case will be something along the lines of "no debug info". Similarly, ERRNUM will be passed as -1 if there is no symbol table, but the function requires a symbol table (e.g., backtrace_syminfo). This may be used as a signal that some other approach should be tried. */ typedef void (*backtrace_error_callback) (void *data, const char *msg, int errnum); /* Get a full stack backtrace. SKIP is the number of frames to skip; passing 0 will start the trace with the function calling backtrace_full. DATA is passed to the callback routine. If any call to CALLBACK returns a non-zero value, the stack backtrace stops, and backtrace returns that value; this may be used to limit the number of stack frames desired. If all calls to CALLBACK return 0, backtrace returns 0. The backtrace_full function will make at least one call to either CALLBACK or ERROR_CALLBACK. This function requires debug info for the executable. */ extern int backtrace_full (int skip, backtrace_full_callback callback, backtrace_error_callback error_callback, void *data); /* The type of the callback argument to the backtrace_simple functio
Re: Backtrace library [1/3]
On Tue, Sep 11, 2012 at 6:08 PM, Ian Lance Taylor wrote: > On Tue, Sep 11, 2012 at 4:01 PM, Gabriel Dos Reis > wrote: >> On Tue, Sep 11, 2012 at 5:53 PM, Ian Lance Taylor wrote: >> >>> This patch is the interface to and configury of libbacktrace. I've >>> separated these out as the parts of libbacktrace that require the most >>> review. The interface to libbacktrace is in the file backtrace.h. This >>> is what callers will use. The file backtrace-supported.h is also >>> available so that programs can see whether calling the backtrace library >>> will work at all. >> >> So, you've settled on a C interface? A C++ interface would have been >> native for other open source projects that are C++ oriented... > > Yes, a C interface is convenient for libgo, and of course is generally > usable. We can certainly layer a C++ interface on top if it seems > useful. > > The interface is somewhat constrained in that, on systems that support > anonymous mmap, it does not call malloc. That makes it possible to do > a symbolic backtrace from a signal handler. I actually liked the uses of mmap where possible -- as opposed to malloc. (which is what I do in my own projects.) I would have expected a C interface layer over a C++ interface, as opposed to the other around -- gaby
Re: Backtrace library [1/3]
On Tue, Sep 11, 2012 at 4:01 PM, Gabriel Dos Reis wrote: > On Tue, Sep 11, 2012 at 5:53 PM, Ian Lance Taylor wrote: > >> This patch is the interface to and configury of libbacktrace. I've >> separated these out as the parts of libbacktrace that require the most >> review. The interface to libbacktrace is in the file backtrace.h. This >> is what callers will use. The file backtrace-supported.h is also >> available so that programs can see whether calling the backtrace library >> will work at all. > > So, you've settled on a C interface? A C++ interface would have been > native for other open source projects that are C++ oriented... Yes, a C interface is convenient for libgo, and of course is generally usable. We can certainly layer a C++ interface on top if it seems useful. The interface is somewhat constrained in that, on systems that support anonymous mmap, it does not call malloc. That makes it possible to do a symbolic backtrace from a signal handler. Ian
Re: Backtrace library [1/3]
On Sep 11, 2012, at 3:53 PM, Ian Lance Taylor wrote: > I have finished the initial implementation of the backtrace library I > proposed at http://gcc.gnu.org/ml/gcc/2012-08/msg00317.html . I've > separated the work into three patches. These patches only implement the > backtrace library itself; actual use of the library will follow in > separate patches. Hi Ian, I have no specific comment on the implementation of this library, but: > > +/* Get a full stack backtrace. SKIP is the number of frames to skip; > + passing 0 will start the trace with the function calling backtrace. > + DATA is passed to the callback routine. If any call to CALLBACK > + returns a non-zero value, the stack backtrace stops, and backtrace > + returns that value; this may be used to limit the number of stack > + frames desired. If all calls to CALLBACK return 0, backtrace > + returns 0. The backtrace function will make at least one call to > + either CALLBACK or ERROR_CALLBACK. This function requires debug > + info for the executable. */ > + > +extern int backtrace (int skip, backtrace_callback callback, > + backtrace_error_callback error_callback, void *data); FYI, "backtrace" is a well-known function provide by glibc (and other libc's). It might be best to pick another name. -Chris
Re: Backtrace library [1/3]
On Tue, Sep 11, 2012 at 5:53 PM, Ian Lance Taylor wrote: > This patch is the interface to and configury of libbacktrace. I've > separated these out as the parts of libbacktrace that require the most > review. The interface to libbacktrace is in the file backtrace.h. This > is what callers will use. The file backtrace-supported.h is also > available so that programs can see whether calling the backtrace library > will work at all. So, you've settled on a C interface? A C++ interface would have been native for other open source projects that are C++ oriented... -- Gaby