From: "wcohen at redhat dot com" <sourceware-bugzilla@sourceware.org>
To: systemtap@sourceware.org
Subject: [Bug translator/23634] WARNING: Can't parse SDT_V3 operand for x86_64 qemu tapset probe points
Date: Wed, 12 Sep 2018 15:03:00 -0000 [thread overview]
Message-ID: <bug-23634-6586-w9YzPPOB9e@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-23634-6586@http.sourceware.org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=23634
--- Comment #3 from William Cohen <wcohen at redhat dot com> ---
sdt.h makes a special case for powerpc:
# ifndef STAP_SDT_ARG_CONSTRAINT
# if defined __powerpc__
# define STAP_SDT_ARG_CONSTRAINT nZr
# else
# define STAP_SDT_ARG_CONSTRAINT nor
# endif
# endif
This was added by:
commit 50f2ef5be3c24b3fe9eb4c9abc386d8dbc3b953a
Author: Sandipan Das <sandipan@linux.vnet.ibm.com>
Date: Thu Oct 5 14:39:41 2017 +0530
powerpc: Change SDT argument constraint
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>
--
You are receiving this mail because:
You are the assignee for the bug.
next prev parent reply other threads:[~2018-09-12 15:03 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-11 19:12 [Bug translator/23634] New: WARNING: Can't parse SDT_V3 operand for x86_64 qemu shared libraries wcohen at redhat dot com
2018-09-11 19:24 ` [Bug translator/23634] WARNING: Can't parse SDT_V3 operand for x86_64 qemu tapset probe points wcohen at redhat dot com
2018-09-12 14:03 ` wcohen at redhat dot com
2018-09-12 14:12 ` fche at redhat dot com
2018-09-12 15:03 ` wcohen at redhat dot com [this message]
2018-09-12 15:56 ` fche at redhat dot com
2020-02-19 21:07 ` fche at redhat dot com
2021-04-15 15:46 ` dgilbert at redhat dot com
2021-04-19 19:15 ` fche at redhat dot com
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=bug-23634-6586-w9YzPPOB9e@http.sourceware.org/bugzilla/ \
--to=sourceware-bugzilla@sourceware.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).