From: Sandipan Das <sandipan@linux.vnet.ibm.com>
To: systemtap@sourceware.org
Cc: naveen.n.rao@linux.vnet.ibm.com, segher@kernel.crashing.org,
mjw@redhat.com, fche@redhat.com
Subject: [PATCH] powerpc: Change SDT argument constraint
Date: Thu, 05 Oct 2017 09:11:00 -0000 [thread overview]
Message-ID: <20171005090941.22701-1-sandipan@linux.vnet.ibm.com> (raw)
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.
$ readelf -n /lib64/libc.so.6 | grep memory_mallopt_mmap_max -A2 -B2
stapsdt 0x0000006c NT_STAPSDT (SystemTap probe descriptors)
Provider: libc
Name: memory_mallopt_mmap_max
Location: 0x00000000000a0274, Base: 0x00000000001ccb90, Semaphore: 0x0000000000000000
Arguments: -4@9 -4@.LANCHOR0+44@toc@l(8) -4@.LANCHOR0+52@toc@l(7)
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.
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.
So, for powerpc, we set STAP_SDT_ARG_CONSTRAINT to 'nZr'
but keep it as 'nor' for all other architectures.
Signed-off-by: Sandipan Das <sandipan@linux.vnet.ibm.com>
---
includes/sys/sdt.h | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/includes/sys/sdt.h b/includes/sys/sdt.h
index f85045851..940f74483 100644
--- a/includes/sys/sdt.h
+++ b/includes/sys/sdt.h
@@ -84,8 +84,12 @@
# define _SDT_ARGFMT(no) %n[_SDT_S##no]@_SDT_ARGTMPL(_SDT_A##no)
# ifndef STAP_SDT_ARG_CONSTRAINT
+# if defined __powerpc__
+# define STAP_SDT_ARG_CONSTRAINT nZr
+# else
# define STAP_SDT_ARG_CONSTRAINT nor
# endif
+# endif
# define _SDT_STRINGIFY(x) #x
# define _SDT_ARG_CONSTRAINT_STRING(x) _SDT_STRINGIFY(x)
--
2.13.6
next reply other threads:[~2017-10-05 9:11 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-05 9:11 Sandipan Das [this message]
2017-10-05 10:16 ` Mark Wielaard
2017-10-05 12:40 ` Segher Boessenkool
2017-10-05 15:59 ` Frank Ch. Eigler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171005090941.22701-1-sandipan@linux.vnet.ibm.com \
--to=sandipan@linux.vnet.ibm.com \
--cc=fche@redhat.com \
--cc=mjw@redhat.com \
--cc=naveen.n.rao@linux.vnet.ibm.com \
--cc=segher@kernel.crashing.org \
--cc=systemtap@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).