From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 106834 invoked by alias); 21 Mar 2018 00:47:18 -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 106778 invoked by uid 89); 21 Mar 2018 00:47:18 -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= 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, 21 Mar 2018 00:47:16 +0000 Received: from librem.wildebeest.org (deer0x01.wildebeest.org [172.31.17.131]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id B800C302BB23 for ; Wed, 21 Mar 2018 01:47:14 +0100 (CET) Received: by librem.wildebeest.org (Postfix, from userid 1000) id 752EC13FD43; Wed, 21 Mar 2018 01:47:14 +0100 (CET) Date: Wed, 21 Mar 2018 00:47:00 -0000 From: Mark Wielaard To: elfutils-devel@sourceware.org Subject: Re: [PATCH] libdwfl: Use process_vm_readv when available. Message-ID: <20180321004714.GH6269@wildebeest.org> References: <20180318004323.21340-1-mark@klomp.org> <20180320232848.GB12453@altlinux.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180320232848.GB12453@altlinux.org> User-Agent: Mutt/1.9.3 (2018-01-21) X-Spam-Flag: NO X-IsSubscribed: yes X-SW-Source: 2018-q1/txt/msg00092.txt.bz2 On Wed, Mar 21, 2018 at 02:28:48AM +0300, Dmitry V. Levin wrote: > On Sun, Mar 18, 2018 at 01:43:23AM +0100, Mark Wielaard wrote: > > + /* Let the ptrace fallback deal with the corner case of the address > > + possibly crossing a page boundery. */ > > + if ((addr & ((Dwarf_Addr)__LIBDWFL_REMOTE_MEM_CACHE_SIZE - 1)) > > + > (Dwarf_Addr)__LIBDWFL_REMOTE_MEM_CACHE_SIZE - sizeof (unsigned long)) > > It looks odd that the variable that is going to be assigned has type > Dwarf_Word, while the size being checked has type unsigned long. > Shouldn't it be sizeof(*result) instead? > > > + d = &mem_cache->buf[addr - mem_cache->addr]; > > + *result = *(unsigned long *) d; > > Likewise, shouldn't it be memcpy(result, d, sizeof(*result)) instead? That is indeed not immediately clear. I'll add some documentation. Although the functions do use Dwarf_Word (which is always 64bits) they actually return the result of an unsigned long/address. This is true for both the pid based and core based memory read functions. I am not completely sure if this was originally deliberate, or if this was the accidental result of the ptrace interface returning a long (target word) for PTRACE_PEEKDATA. Thanks for reviewing. Cheers, Mark