From patchwork Sat Nov 16 18:28:19 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ian Lance Taylor X-Patchwork-Id: 291793 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id E36312C00DC for ; Sun, 17 Nov 2013 05:28:40 +1100 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :mime-version:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; q=dns; s=default; b=eo55EjUsojZEHE68Gg oDaBZFClrXZzL4VOYEGL9bbLRU4CKWFd7lgfI6EmXKVfXQWOtIqbu6E7k25ZWpMa 2bfR5OgerHAxFd0+Q6SAVJSJkzzc1jdDjYByKkBmvv3cUCFQHrAvZbdgn6CVmdmi +lE/+qUYtJzgnsyJDv/AnSj9s= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :mime-version:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; s=default; bh=dnRWkIhYQS43f+2LY13h2UaH xwQ=; b=MH7CqFPMfk7MVUdlwNsXMvwygDltL5RT5rd19PrjagwjYRBkLZcQUS0X bsz/gGD7ysEbzk4Oc+ptwvq5lV/28bXaP5/12oA7Pe4y5wRO5cx8TsYUsA+09rW0 DsbxbbWIvsS3voM8yJWanZ849yQ7ZycaXcFZv8rEx42N81BHzGM= Received: (qmail 15967 invoked by alias); 16 Nov 2013 18:28:29 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 15956 invoked by uid 89); 16 Nov 2013 18:28:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.6 required=5.0 tests=AWL, BAYES_50, RDNS_NONE, SPF_PASS autolearn=no version=3.3.2 X-HELO: mail-oa0-f42.google.com Received: from Unknown (HELO mail-oa0-f42.google.com) (209.85.219.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Sat, 16 Nov 2013 18:28:27 +0000 Received: by mail-oa0-f42.google.com with SMTP id h16so5467370oag.1 for ; Sat, 16 Nov 2013 10:28:19 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Uq9kWiNlsKtBME+uY05vHaDoV/kIIUBEBAbQV1k/acE=; b=m2QSDrkuy62C6be+sWcuAUakCceAzv2W+OXTrWoaiNniRJXbvkh7/70L+K4r43rWYt Hv5BA7hnEzCYohl2KI7VBPpZbz0xRPMvrV45Y0ngAZrro35MLFk50+UNBfyUvohFuIIE +M6wavJ7A+bteD/8OOm/VEH2OAr+sKBEzk0PlGRpNRA2YCio15VjslmKS0qZbFVnidAk pOQ+9ZACAVEbDAT/ADVNZkw7zDVndBHbzD9j6kcwfkISTE3OkVEsK9kWg1ha6SrsZzn8 gbz+W9e2PVYF9B69+dARb17LHhDED9wS0zkR+Ty7zwgZsi03N13hw46Y7cJ1ObxKJv1u 2Ouw== X-Gm-Message-State: ALoCoQncPFXCTTM9/A1RIi8wS/hJwSER1odBRU6VQu9lm9PPUHXUo+jvYUPNqJ0mh0BW36/usuxXuBOrJcjXddjzj8IrGuw2GIHLt2OB3Ss22DZ3Hukxlb3B16bikzbVSVZKdxmwq3F/JKSlBS4DqIc1Ws3rHXKRaSnpKXvgEQKoIF2kNzblB4kE5a/lM8Gns1YoENMhJ4aI5wdrV36zPsIqIjonHKSTjw== MIME-Version: 1.0 X-Received: by 10.182.87.42 with SMTP id u10mr12628529obz.22.1384626499298; Sat, 16 Nov 2013 10:28:19 -0800 (PST) Received: by 10.60.145.144 with HTTP; Sat, 16 Nov 2013 10:28:19 -0800 (PST) In-Reply-To: <20131115213442.GR892@tucnak.redhat.com> References: <20131115213442.GR892@tucnak.redhat.com> Date: Sat, 16 Nov 2013 10:28:19 -0800 Message-ID: Subject: Re: libbacktrace patch RFC: Look up variables in backtrace_syminfo From: Ian Lance Taylor To: Jakub Jelinek Cc: gcc-patches X-IsSubscribed: yes On Fri, Nov 15, 2013 at 1:34 PM, Jakub Jelinek wrote: > On Fri, Nov 15, 2013 at 01:26:54PM -0800, Ian Lance Taylor wrote: >> Jakub asked whether it would be possible to extend backtrace_syminfo to >> work for variables as well as functions. It's a straightforward >> extension, implemented by this patch. Bootstrapped and ran libbacktrace >> tests on x86_64-unknown-linux-gnu. Any comments on this patch before I >> submit it? > > Looks good to me. Committed. > OT, > > permanent buffer. If THREADED is non-zero the state may be > accessed by multiple threads simultaneously, and the library will > use appropriate locks (this requires that the library be configured > with --enable-backtrace-threads). If THREADED is zero the state > > in backtrace.h in backtrace_create_state comment doesn't look to be > up to date, there is no --enable-backtrace-threads it seems, just > depending on configure either it is thread safe or not (and doesn't use > locks). Thanks. I committed the following patch to correct the comment. Ian 2013-11-16 Ian Lance Taylor * backtrace.h (backtrace_create_state): Correct comment about threading. Index: backtrace.h =================================================================== --- backtrace.h (revision 204904) +++ backtrace.h (working copy) @@ -89,8 +89,7 @@ typedef void (*backtrace_error_callback) system-specific path names. If not NULL, FILENAME must point to a permanent buffer. If THREADED is non-zero the state may be accessed by multiple threads simultaneously, and the library will - use appropriate locks (this requires that the library be configured - with --enable-backtrace-threads). If THREADED is zero the state + use appropriate atomic operations. If THREADED is zero the state may only be accessed by one thread at a time. This returns a state pointer on success, NULL on error. If an error occurs, this will call the ERROR_CALLBACK routine. */