public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
From: "sapatel at redhat dot com" <sourceware-bugzilla@sourceware.org>
To: systemtap@sourceware.org
Subject: [Bug bpf/24926] non-ascii characters not printing on stapbpf
Date: Wed, 28 Aug 2019 21:26:00 -0000	[thread overview]
Message-ID: <bug-24926-6586-F2mwXa4LPK@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-24926-6586@http.sourceware.org/bugzilla/>

https://sourceware.org/bugzilla/show_bug.cgi?id=24926

--- Comment #3 from Sagar Patel <sapatel at redhat dot com> ---
The root issue is that the immediate values carried by instructions only
support 32-bit integers, and the compiler performs some problematic fixups. 

When strings are rolled into their byte representations, a generic value struct
is used. This struct holds an int64_t immediate value which represents the
string and is used as the src1 register in the insn struct. However, the insn
struct only supports 32-bit integers in its src1 registers. 

There is a check in fixup_operands that checks for these mismatches: 

s1->imm() != (int32_t) s1->imm()


Normally, the first bit of a character would just be 0, since ASCII only goes
upto 127. Consequently, when strings with plain ASCII characters get converted
to an immediate value, the most significant bit is not set and no fixups are
done because the above check is satisfied.

However, for UTF-8 characters, the most significant bit may be set causing the
compiler to perform some fixups. In the fixups, an intermediate register is
used to store and load and the string bytes. The original insn that was
generated for the strings uses the 0x62 opcode: stw [dst+off], imm. But, since
we have an intermediate register holding the data, we need to use the 0x63
opcode instead: stxw [dst+off], src.

The changing of the opcode from 0x62 to 0x63 was missing, and with that change,
it seems that all UTF-8 characters can be printed.

-- 
You are receiving this mail because:
You are the assignee for the bug.

  parent reply	other threads:[~2019-08-28 21:26 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-21 16:10 [Bug bpf/24926] New: " sapatel at redhat dot com
2019-08-21 22:05 ` [Bug bpf/24926] " me at serhei dot io
2019-08-26 18:04 ` sapatel at redhat dot com
2019-08-28 21:26 ` sapatel at redhat dot com [this message]
2019-09-03 20:07 ` sapatel 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-24926-6586-F2mwXa4LPK@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).