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 dnovi...@google.com wrote: On 2012-09-11 18:53 , Ian Lance Taylor wrote: 2012-09-11 Ian Lance Taylor i...@google.com * 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]
On Wed, Sep 19, 2012 at 1:56 PM, Ryan Mansfield rmansfi...@qnx.com 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-19 06:17 PM, Ian Lance Taylor wrote: On Wed, Sep 19, 2012 at 1:56 PM, Ryan Mansfield rmansfi...@qnx.com 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 3:31 PM, Ryan Mansfield rmansfi...@qnx.com 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 i...@google.com * 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: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 i...@google.com * configure.ac: Only use GCC_CHECK_UNWIND_GETIPINFO when compiled as a target library. * configure: Rebuild.
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]
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 Thu, Sep 13, 2012 at 1:00 PM, Diego Novillo dnovi...@google.com wrote: On 2012-09-11 18:53 , Ian Lance Taylor wrote: 2012-09-11 Ian Lance Taylor i...@google.com * 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 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 ger...@pfeifer.com
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 Mon, Sep 17, 2012 at 2:00 PM, Gerald Pfeifer ger...@pfeifer.com 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 i...@google.com 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, Sep 17, 2012 at 2:00 PM, Gerald Pfeifer ger...@pfeifer.com 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 2012-09-11 18:53 , Ian Lance Taylor wrote: 2012-09-11 Ian Lance Taylor i...@google.com * Initial implementation. OK. Diego.
Re: Backtrace library [1/3]
On Tue, Sep 11, 2012 at 4:36 PM, Lawrence Crowl cr...@googlers.com wrote: On 9/11/12, Ian Lance Taylor i...@google.com 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, 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 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 9/12/12, Ian Lance Taylor i...@google.com wrote: On Sep 11, 2012 Lawrence Crowl cr...@googlers.com wrote: On 9/11/12, Ian Lance Taylor i...@google.com 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 Wed, Sep 12, 2012 at 9:23 AM, Joseph S. Myers jos...@codesourcery.com 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 Wed, Sep 12, 2012 at 10:31 AM, Lawrence Crowl cr...@googlers.com 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, 12 Sep 2012, Ian Lance Taylor wrote: On Wed, Sep 12, 2012 at 9:23 AM, Joseph S. Myers jos...@codesourcery.com 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 2:04 PM, Joseph S. Myers jos...@codesourcery.com wrote: On Wed, 12 Sep 2012, Ian Lance Taylor wrote: On Wed, Sep 12, 2012 at 9:23 AM, Joseph S. Myers jos...@codesourcery.com 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.
Backtrace library [1/3]
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.
This initial implementation only supports ELF and DWARF. The library is
designed to work correctly for other cases, in the sense that it will
report that it can not find any backtrace information. The library is
designed to make it straightforward to add support for other object file
formats and debugging formats. My intent is to commit the library with
ELF/DWARF support and then support other people in extending it. In
particular, adding support for Mach-O and PE with DWARF should be
simple.
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 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).
Bootstrapped on x86_64-unknown-linux-gnu in conjunction with the other
two patches. OK for mainline?
Ian
2012-09-11 Ian Lance Taylor i...@google.com
* Initial implementation.
Index: libbacktrace/README
===
--- libbacktrace/README (revision 0)
+++ libbacktrace/README (revision 0)
@@ -0,0 +1,23 @@
+The libbacktrace library
+Initially written by Ian Lance Taylor i...@google.com
+
+The libbacktrace library may be linked into a program or library and
+used to produce symbolic backtraces. Sample uses would be to print a
+detailed backtrace when an error occurs or to gather detailed
+profiling information.
+
+The libbacktrace library is provided under a BSD license. See the
+source files for the exact license text.
+
+The public functions are declared and documented in the header file
+backtrace.h, which should be #include'd by a user of the library.
+
+Building libbacktrace will generate a file backtrace-supported.h,
+which a user of the library may use to determine whether backtraces
+will work. See the source file backtrace-supported.h.in for the
+macros that it defines.
+
+As of September 2012, libbacktrace only supports ELF executables with
+DWARF debugging information. The library is written to make it
+straightforward to add support for other object file and debugging
+formats.
Index: libbacktrace/backtrace.h
===
--- libbacktrace/backtrace.h (revision 0)
+++ libbacktrace/backtrace.h (revision 0)
@@ -0,0 +1,165 @@
+/* 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 stddef.h
+#include stdint.h
+#include stdio.h
+
+#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
Re: Backtrace library [1/3]
On Tue, Sep 11, 2012 at 5:53 PM, Ian Lance Taylor i...@google.com 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
Re: Backtrace library [1/3]
On Sep 11, 2012, at 3:53 PM, Ian Lance Taylor i...@google.com 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 4:01 PM, Gabriel Dos Reis g...@integrable-solutions.net wrote: On Tue, Sep 11, 2012 at 5:53 PM, Ian Lance Taylor i...@google.com 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 Tue, Sep 11, 2012 at 6:08 PM, Ian Lance Taylor i...@google.com wrote: On Tue, Sep 11, 2012 at 4:01 PM, Gabriel Dos Reis g...@integrable-solutions.net wrote: On Tue, Sep 11, 2012 at 5:53 PM, Ian Lance Taylor i...@google.com 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:07 PM, Chris Lattner clatt...@apple.com 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 stddef.h
#include stdint.h
#include stdio.h
#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
Re: Backtrace library [1/3]
On 9/11/12, Ian Lance Taylor i...@google.com 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:36 PM, Lawrence Crowl cr...@googlers.com wrote: On 9/11/12, Ian Lance Taylor i...@google.com 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 Sep 11, 2012, at 4:24 PM, Ian Lance Taylor i...@google.com wrote: On Tue, Sep 11, 2012 at 4:07 PM, Chris Lattner clatt...@apple.com 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 9:36 PM, Chris Lattner clatt...@apple.com wrote: On Sep 11, 2012, at 4:24 PM, Ian Lance Taylor i...@google.com wrote: On Tue, Sep 11, 2012 at 4:07 PM, Chris Lattner clatt...@apple.com 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 Tue, Sep 11, 2012 at 11:49 PM, Ian Lance Taylor i...@google.com wrote: On Tue, Sep 11, 2012 at 9:36 PM, Chris Lattner clatt...@apple.com wrote: On Sep 11, 2012, at 4:24 PM, Ian Lance Taylor i...@google.com wrote: On Tue, Sep 11, 2012 at 4:07 PM, Chris Lattner clatt...@apple.com 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
