From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 66550 invoked by alias); 5 Oct 2017 10:16:28 -0000 Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org Received: (qmail 66492 invoked by uid 89); 5 Oct 2017 10:16:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 spammy=Hx-languages-length:1533 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; Thu, 05 Oct 2017 10:16:26 +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 22AB5302BB21; Thu, 5 Oct 2017 12:16:23 +0200 (CEST) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id CEFC44000985; Thu, 5 Oct 2017 12:16:23 +0200 (CEST) Message-ID: <1507198583.9961.29.camel@klomp.org> Subject: Re: [PATCH] powerpc: Change SDT argument constraint From: Mark Wielaard To: Sandipan Das , systemtap@sourceware.org Cc: naveen.n.rao@linux.vnet.ibm.com, segher@kernel.crashing.org, fche@redhat.com Date: Thu, 05 Oct 2017 10:16:00 -0000 In-Reply-To: <20171005090941.22701-1-sandipan@linux.vnet.ibm.com> References: <20171005090941.22701-1-sandipan@linux.vnet.ibm.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 X-IsSubscribed: yes X-SW-Source: 2017-q4/txt/msg00006.txt.bz2 On Thu, 2017-10-05 at 14:39 +0530, Sandipan Das wrote: > With the 'o' memory constraint, any memory operand which > has an offsettable address is allowed. However, for some > architectures such as powerpc, this allows operands like > the ones shown below in the readelf output from Fedora 26 > to be generated. >=20 > =C2=A0 $ readelf -n /lib64/libc.so.6 | grep memory_mallopt_mmap_max -A2 > -B2 > =C2=A0=C2=A0=C2=A0=C2=A0stapsdt=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A00x0000006c NT_STAPSDT (SystemTap > probe descriptors) > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Provider: libc > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Name: memory_mallopt_mmap_max > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Location: 0x00000000000a0274, Base: 0= x00000000001ccb90, > Semaphore: 0x0000000000000000 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Arguments: -4@9 -4@.LANCHOR0+44@toc@l= (8) -4@.LANCHOR0+52@toc@l( > 7) >=20 > The second and third argument shown above are both having > operands which are pointers to static data anchors. Since > these static anchors are not included in the symbol table, > they cannot be resolved from the binary itself. So, such > arguments cannot be read via their corresponding markers. >=20 > Using the 'Z' memory constraint instead solves this issue > as it will only allow a memory operand that is an indexed > or indirect from a register. >=20 > So, for powerpc, we set STAP_SDT_ARG_CONSTRAINT to 'nZr' > but keep it as 'nor' for all other architectures. I haven't tested it, but just reading the machine constraints page https://gcc.gnu.org/onlinedocs/gcc/Machine-Constraints.html it looks correct to me. Thanks, Mark