On Mon, Nov 25, 2013 at 7:02 PM, Jakub Jelinek ja...@redhat.com wrote:
On Mon, Nov 25, 2013 at 06:53:59PM +0400, Alexey Samsonov wrote:
In GCC, libbacktrace is built as a libtool convenience library only and
then linked into whatever libraries want to use it. So indeed, the plan
is to link
On Wed, Nov 27, 2013 at 04:12:33PM +0400, Alexey Samsonov wrote:
Sure, worst case you keep it untested in your LLVM copy of libsanitizer
and we'll just need to fix it up during merges if something breaks.
If it will be used for GCC (and we have a P1 bug so it is a release blocker
if
On Wed, Nov 27, 2013 at 4:20 PM, Jakub Jelinek ja...@redhat.com wrote:
On Wed, Nov 27, 2013 at 04:12:33PM +0400, Alexey Samsonov wrote:
Sure, worst case you keep it untested in your LLVM copy of libsanitizer
and we'll just need to fix it up during merges if something breaks.
If it will be
On Wed, Nov 27, 2013 at 04:31:48PM +0400, Alexey Samsonov wrote:
LLVM emits just a DW_AT_low_pc (base address of a compilation unit). The
standard tells that compilation unit entries may have attributes
specifying the
address range, but doesn't tell they are obligatory.
DWARF consumers
On Wed, Nov 27, 2013 at 4:51 PM, Jakub Jelinek ja...@redhat.com wrote:
On Wed, Nov 27, 2013 at 04:31:48PM +0400, Alexey Samsonov wrote:
LLVM emits just a DW_AT_low_pc (base address of a compilation unit). The
standard tells that compilation unit entries may have attributes
specifying the
On Wed, Nov 27, 2013 at 4:31 AM, Alexey Samsonov samso...@google.com wrote:
LLVM emits just a DW_AT_low_pc (base address of a compilation unit). The
standard tells that compilation unit entries may have attributes
specifying the
address range, but doesn't tell they are obligatory.
DWARF
On Wed, Nov 27, 2013 at 9:44 PM, Ian Lance Taylor i...@google.com wrote:
On Wed, Nov 27, 2013 at 4:31 AM, Alexey Samsonov samso...@google.com wrote:
LLVM emits just a DW_AT_low_pc (base address of a compilation unit). The
standard tells that compilation unit entries may have attributes
On Wed, Nov 27, 2013 at 10:05 AM, Alexey Samsonov samso...@google.com wrote:
Sorry, I wasn't clear enough. GCC emits DW_AT_low_pc and DW_AT_high_pc for
*compile unit* DIE, so the consumer doesn't have to iterate over all
the functions DIEs.
LLVM doesn't emit DW_AT_low_pc/DW_AT_high_pc for
On Wed, Nov 27, 2013 at 04:51:46PM -0800, Ian Lance Taylor wrote:
OK to commit in stage 3?
Yes, thanks.
2013-11-27 Ian Lance Taylor i...@google.com
* dwarf.c (find_address_ranges): New static function, broken out
of build_address_map.
(build_address_map): Call it.
[plain text version]
Tool-specific actions in the interceptors are disabled when we enter
the symbolizer.
What happens if user app links libbacktrace? An instrumented
libbacktrace? Memory that is allocated internally in sanitizer runtime
is not unpoisoned; for example, asan may consider it
On Tue, Nov 26, 2013 at 03:00:27PM +0400, Evgeniy Stepanov wrote:
[plain text version]
Tool-specific actions in the interceptors are disabled when we enter
the symbolizer.
What happens if user app links libbacktrace? An instrumented
libbacktrace? Memory that is allocated internally in
On Fri, Nov 22, 2013 at 10:34 PM, Jakub Jelinek ja...@redhat.com wrote:
On Fri, Nov 22, 2013 at 10:19:02PM +0400, Alexey Samsonov wrote:
On Tue, Nov 19, 2013 at 8:42 PM, Jakub Jelinek ja...@redhat.com wrote:
Ok, here it is (untested though, because libsanitizer in gcc is older and I
don't
On Mon, Nov 25, 2013 at 06:53:59PM +0400, Alexey Samsonov wrote:
In GCC, libbacktrace is built as a libtool convenience library only and
then linked into whatever libraries want to use it. So indeed, the plan
is to link libbacktrace.la into libasan.so.1.0.0 and libasan.a
(and the earlier
On Tue, Nov 19, 2013 at 8:42 PM, Jakub Jelinek ja...@redhat.com wrote:
On Tue, Nov 19, 2013 at 04:33:50PM +0100, Jakub Jelinek wrote:
I will try.
Ok, here it is (untested though, because libsanitizer in gcc is older and I
don't have spare cycles to play with llvm).
Guess you need to write
On Fri, Nov 22, 2013 at 10:19 AM, Alexey Samsonov samso...@google.com wrote:
On Tue, Nov 19, 2013 at 8:42 PM, Jakub Jelinek ja...@redhat.com wrote:
On Tue, Nov 19, 2013 at 04:33:50PM +0100, Jakub Jelinek wrote:
I will try.
Ok, here it is (untested though, because libsanitizer in gcc is
On Fri, Nov 22, 2013 at 10:19:02PM +0400, Alexey Samsonov wrote:
On Tue, Nov 19, 2013 at 8:42 PM, Jakub Jelinek ja...@redhat.com wrote:
Ok, here it is (untested though, because libsanitizer in gcc is older and I
don't have spare cycles to play with llvm).
Guess you need to write it up into
[I beg my pardon if this has already been discussed here]
Does libbacktrace call any functions we intercept (malloc, memset,
memcpy, strlen, etc)?
If so, they will have to be un-intercepted there.
Our hermetic llvm-symbolizer took as so much work for a reason. :(
And doing this work for
On Fri, Nov 22, 2013 at 10:40:00PM +0400, Konstantin Serebryany wrote:
[I beg my pardon if this has already been discussed here]
Does libbacktrace call any functions we intercept (malloc, memset,
memcpy, strlen, etc)?
If so, they will have to be un-intercepted there.
Why?
Our hermetic
+eugenis, dvyukov
libbacktrace doesn't call malloc -- good.
Most other functions it does call (memset,strlen, etc) will be
rerouted to sanitizer interceptors.
This is just generally scary and I think we've been hit by this in
reality with early llvm-symbolizer.
More likely in tsan and msan than in
On Fri, Nov 22, 2013 at 11:13:26PM +0400, Konstantin Serebryany wrote:
+eugenis, dvyukov
libbacktrace doesn't call malloc -- good.
Most other functions it does call (memset,strlen, etc) will be
rerouted to sanitizer interceptors.
This is just generally scary and I think we've been hit by this
On Mon, Nov 18, 2013 at 09:09:03AM -0800, Ian Lance Taylor wrote:
2) for tsan querying of data symbols, apparently the classes want to see
not just the symbol name and start value, but also size. libbacktrace
has all this info available, just doesn't pass it down to the callback.
On Mon, Nov 18, 2013 at 11:44 PM, Jakub Jelinek ja...@redhat.com wrote:
On Tue, Nov 19, 2013 at 05:32:12PM +1030, Alan Modra wrote:
On Tue, Nov 19, 2013 at 06:17:41AM +0100, Hans-Peter Nilsson wrote:
In file included from /tmp/x/gcc/libbacktrace/atomic.c:37:
On Tue, Nov 19, 2013 at 12:04 AM, Jakub Jelinek ja...@redhat.com wrote:
On Mon, Nov 18, 2013 at 09:09:03AM -0800, Ian Lance Taylor wrote:
2) for tsan querying of data symbols, apparently the classes want to see
not just the symbol name and start value, but also size. libbacktrace
has
On Tue, Nov 19, 2013 at 06:43:07AM -0800, Ian Lance Taylor wrote:
2013-11-19 Jakub Jelinek ja...@redhat.com
* backtrace.h (backtrace_syminfo_callback): Add symsize argument.
* elf.c (elf_syminfo): Pass 0 or sym-size to the callback as
last argument.
*
Hi Jakub,
Can you please an updated patch in the attachment?
On Mon, Nov 18, 2013 at 8:23 PM, Jakub Jelinek ja...@redhat.com wrote:
On Mon, Nov 18, 2013 at 07:50:33PM +0400, Alexey Samsonov wrote:
On Mon, Nov 18, 2013 at 7:49 PM, Alexey Samsonov samso...@google.com wrote:
Unfortunately,
On Tue, Nov 19, 2013 at 07:14:03PM +0400, Alexey Samsonov wrote:
+#if SANITIZER_LIBBACKTRACE
+namespace {
+
+struct SymbolizeCodeData {
+ AddressInfo *frames;
+ uptr n_frames;
+ uptr max_frames;
max_frames is not used anywhere.
I guess
if (cdata-n_frames ==
On Tue, Nov 19, 2013 at 04:33:50PM +0100, Jakub Jelinek wrote:
I will try.
Ok, here it is (untested though, because libsanitizer in gcc is older and I
don't have spare cycles to play with llvm).
Guess you need to write it up into compiler-rt buildsystem somehow,
and for testing add
(resending in plain text)
On Mon, Nov 18, 2013 at 7:49 PM, Alexey Samsonov samso...@google.com wrote:
Hi Jakub,
Unfortunately, recently there were a few enhancements to
sanitizer_symbolizer_posix_libcdep.cc (and friends),
in LLVM trunk, and now it looks different from gcc version
On Mon, Nov 18, 2013 at 07:49:03PM +0400, Alexey Samsonov wrote:
As for sanitizer, the reason I haven't implemented SendCommand method for
the libbacktrace symbolizer is that the library doesn't provide the info
as text, but as individual values passed to the callback, so printing
that to
On Mon, Nov 18, 2013 at 07:50:33PM +0400, Alexey Samsonov wrote:
On Mon, Nov 18, 2013 at 7:49 PM, Alexey Samsonov samso...@google.com wrote:
Unfortunately, recently there were a few enhancements to
sanitizer_symbolizer_posix_libcdep.cc (and friends),
in LLVM trunk, and now it looks
On Mon, Nov 18, 2013 at 5:39 AM, Jakub Jelinek ja...@redhat.com wrote:
I've kept the possibility to override the symbolizer by magic symbols
(InternalSymbolizer), and as I have no idea how the llvm buildsystem etc.
works and what is the possibility there to add libbacktrace, this just
On Mon, Nov 18, 2013 at 9:09 AM, Ian Lance Taylor i...@google.com wrote:
On Mon, Nov 18, 2013 at 5:39 AM, Jakub Jelinek ja...@redhat.com wrote:
3) I wonder if libbacktrace couldn't be updated to use __atomic_* builtins,
then it could avoid the ugliness to emulate atomic loads and stores.
On Mon, Nov 18, 2013 at 10:26:58AM -0800, Ian Lance Taylor wrote:
On Mon, Nov 18, 2013 at 9:09 AM, Ian Lance Taylor i...@google.com wrote:
On Mon, Nov 18, 2013 at 5:39 AM, Jakub Jelinek ja...@redhat.com wrote:
3) I wonder if libbacktrace couldn't be updated to use __atomic_* builtins,
On Mon, Nov 18, 2013 at 12:14 PM, Jakub Jelinek ja...@redhat.com wrote:
Sure, but GCC itself doesn't need the thread-safe stuff, and the target
libbacktrace is built with gcc and will have __atomic_* support.
You already have there configure checks for the __sync_* builtins, just
replacing
From: Ian Lance Taylor i...@google.com
Date: Tue, 19 Nov 2013 02:11:29 +0100
2013-11-18 Ian Lance Taylor i...@google.com
* configure.ac: Check for support of __atomic extensions.
* internal.h: Declare or #define atomic functions for use in
backtrace code.
*
On Tue, Nov 19, 2013 at 06:17:41AM +0100, Hans-Peter Nilsson wrote:
In file included from /tmp/x/gcc/libbacktrace/atomic.c:37:
/tmp/x/gcc/libbacktrace/internal.h:182: error: expected declaration
specifiers or '...' before 'off_t'
make[3]: *** [atomic.lo] Error 1
brgds, H-P
PS. Host is
On Tue, Nov 19, 2013 at 05:32:12PM +1030, Alan Modra wrote:
On Tue, Nov 19, 2013 at 06:17:41AM +0100, Hans-Peter Nilsson wrote:
In file included from /tmp/x/gcc/libbacktrace/atomic.c:37:
/tmp/x/gcc/libbacktrace/internal.h:182: error: expected declaration
specifiers or '...' before 'off_t'
37 matches
Mail list logo
