From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17383 invoked by alias); 28 Mar 2018 14:33:31 -0000 Mailing-List: contact elfutils-devel-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: elfutils-devel-owner@sourceware.org Received: (qmail 16370 invoked by uid 89); 28 Mar 2018 14:33:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.99.4 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=whenever X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: gnu.wildebeest.org Received: from wildebeest.demon.nl (HELO gnu.wildebeest.org) (212.238.236.112) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 28 Mar 2018 14:33:29 +0000 Received: from tarox.wildebeest.org (tarox.wildebeest.org [172.31.17.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id A9E6E3014710 for ; Wed, 28 Mar 2018 16:33:26 +0200 (CEST) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id 5E402413CD0D; Wed, 28 Mar 2018 16:33:26 +0200 (CEST) Message-ID: <1522247606.15770.68.camel@klomp.org> Subject: Re: [PATCH] libdwfl: Use process_vm_readv when available. From: Mark Wielaard To: elfutils-devel@sourceware.org Date: Wed, 28 Mar 2018 14:33:00 -0000 In-Reply-To: <20180320223202.GE6269@wildebeest.org> References: <20180318004323.21340-1-mark@klomp.org> <20180320223202.GE6269@wildebeest.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.22.6 (3.22.6-10.el7) Mime-Version: 1.0 X-Spam-Flag: NO X-IsSubscribed: yes X-SW-Source: 2018-q1/txt/msg00115.txt.bz2 On Tue, 2018-03-20 at 23:32 +0100, Mark Wielaard wrote: > On Sun, Mar 18, 2018 at 01:43:23AM +0100, Mark Wielaard wrote: > > If possible use process_vm_readv to read 4K blocks instead of fetching > > each word individually with ptrace. For unwinding this often means we > > only have to do one process_vm_readv of the stack instead of dozens of > > ptrace calls. There is one 4K cache per process, cleared whenever a > > thread is detached. >=20 > It seems to work well, but the GCC undefined sanitizer > (configure --enable-sanitize-undefined) found an issue in the > run-backtrace-native-biarch.sh testcase (from x86_64 to i686) > when reading unaligned data. To fix that don't assign to the > Dwarf_Word directly when unaligned, but use memcpy (which gcc > seems to inline). I pushed this to master now. Adding some comments about the word size being actually architecture defined even though we use a 64bit Dwarf_Word everywhere. Cheers, Mark