<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE bugzilla SYSTEM "https://bugs.kde.org/page.cgi?id=bugzilla.dtd">

<bugzilla version="5.0.6"
          urlbase="https://bugs.kde.org/"
          
          maintainer="sysadmin@kde.org"
>

    <bug>
          <bug_id>134478</bug_id>
          
          <creation_ts>2006-09-21 23:54:08 +0000</creation_ts>
          <short_desc>(cli, sti) vex amd64-&gt;IR: unhandled instruction bytes: 0xFA 0xC7 0x45 0xFC</short_desc>
          <delta_ts>2010-11-11 19:51:42 +0000</delta_ts>
          <reporter_accessible>1</reporter_accessible>
          <cclist_accessible>1</cclist_accessible>
          <classification_id>6</classification_id>
          <classification>Developer tools</classification>
          <product>valgrind</product>
          <component>vex</component>
          <version>3.2.1</version>
          <rep_platform>Unlisted Binaries</rep_platform>
          <op_sys>Linux</op_sys>
          <bug_status>UNCONFIRMED</bug_status>
          <resolution></resolution>
          
          
          <bug_file_loc></bug_file_loc>
          <status_whiteboard></status_whiteboard>
          <keywords></keywords>
          <priority>NOR</priority>
          <bug_severity>crash</bug_severity>
          <target_milestone>---</target_milestone>
          
          <blocked>253451</blocked>
          <everconfirmed>0</everconfirmed>
          <reporter name="Yousong Mei">YousongMei</reporter>
          <assigned_to name="Julian Seward">jseward</assigned_to>
          <cc>njn</cc>
          
          <cf_commitlink></cf_commitlink>
          <cf_versionfixedin></cf_versionfixedin>
          <cf_sentryurl></cf_sentryurl>
          <votes>0</votes>

      

      

      

          <comment_sort_order>oldest_to_newest</comment_sort_order>  
          <long_desc isprivate="0" >
    <commentid>471812</commentid>
    <comment_count>0</comment_count>
    <who name="Yousong Mei">YousongMei</who>
    <bug_when>2006-09-21 23:54:08 +0000</bug_when>
    <thetext>valgrind 3.2.1 report &quot;illegal instruction&quot; for code that has CLI/STI.
e.g. with the following code,
int main()
{
   volatile int x;
   asm volatile (&quot;cli&quot;);
   x = 0;
   asm volatile (&quot;sti&quot;);
   return 0;
}

Valgrind -v generates the following output:-
--14078-- Command line
--14078--    a.out
--14078-- Startup, with flags:
--14078--    -v
--14078-- Contents of /proc/version:
--14078--   Linux version 2.6.16-18_yoda2smp (orbuild@yoran-bldsvr5) (gcc
version 4.0.2 20051125 (Red Hat 4.0.2-8)) #1 SMP PREEMPT Fri May 26 11:33:53 PDT
2006
--14078-- Arch and hwcaps: AMD64, amd64-sse2
--14078-- Valgrind library directory: /opt/or-develtools/lib/valgrind
--14078-- Reading syms from /home/ymei/a.out (0x400000)
--14078-- Reading syms from
/orenv/develtools-fc4-x86_64-ro/lib/valgrind/amd64-linux/memcheck (0x38000000)
--14078--    object doesn&apos;t have a symbol table
--14078--    object doesn&apos;t have a dynamic symbol table
--14078-- Reading suppressions file: /opt/or-develtools/lib/valgrind/default.supp
--14078-- Reading syms from
/orenv/develtools-fc4-x86_64-ro/lib/valgrind/amd64-linux/vgpreload_core.so
(0x4802000)
--14078--    object doesn&apos;t have a symbol table
--14078-- Reading syms from
/orenv/develtools-fc4-x86_64-ro/lib/valgrind/amd64-linux/vgpreload_memcheck.so
(0x4903000)
--14078--    object doesn&apos;t have a symbol table
--14078-- REDIR: 0x3DE4C13F90 (index) redirected to 0x4906720 (index)
--14078-- REDIR: 0x3DE4C14140 (strcmp) redirected to 0x49068B0 (strcmp)
--14078-- REDIR: 0x3DE4C14170 (strlen) redirected to 0x49067C0 (strlen)
--14078-- Reading syms from /usr/lib64/libstdc++.so.6.0.7 (0x3DE7500000)
--14078--    object doesn&apos;t have a symbol table
--14078-- Reading syms from /lib64/libm-2.3.5.so (0x3DE5100000)
--14078-- Reading syms from /lib64/libgcc_s-4.0.2-20051126.so.1 (0x3DE6D00000)
--14078--    object doesn&apos;t have a symbol table
--14078-- Reading syms from /lib64/libc-2.3.5.so (0x3DE4E00000)
--14078-- REDIR: 0x3DE4E72420 (rindex) redirected to 0x49065D0 (rindex)
vex amd64-&gt;IR: unhandled instruction bytes: 0xFA 0xC7 0x45 0xFC
==14078== valgrind: Unrecognised instruction at address 0x40051C.
==14078== Your program just tried to execute an instruction that Valgrind
==14078== did not recognise.  There are two possible reasons for this.
==14078== 1. Your program has a bug and erroneously jumped to a non-code
==14078==    location.  If you are running Memcheck and you just saw a
==14078==    warning about a bad jump, it&apos;s probably your program&apos;s fault.
==14078== 2. The instruction is legitimate but Valgrind doesn&apos;t handle it,
==14078==    i.e. it&apos;s Valgrind&apos;s fault.  If you think this is the case or
==14078==    you are not sure, please let us know and we&apos;ll try to fix it.
==14078== Either way, Valgrind will now raise a SIGILL signal which will
==14078== probably kill your program.
==14078== 
==14078== Process terminating with default action of signal 4 (SIGILL): dumping core
==14078==  Illegal opcode at address 0x40051C
==14078==    at 0x40051C: main (in /home/ymei/a.out)
--14078-- REDIR: 0x3DE4E6ABE0 (free) redirected to 0x490575E (free)
--14078-- REDIR: 0x3DE4E733E0 (memset) redirected to 0x4906B00 (memset)
==14078== 
==14078== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 5 from 2)
--14078-- supp:    1 strlen-not-intercepted-early-enough-HACK-5
--14078-- supp:    4 dl_relocate_object
==14078== malloc/free: in use at exit: 0 bytes in 0 blocks.
==14078== malloc/free: 0 allocs, 0 frees, 0 bytes allocated.
==14078== 
==14078== All heap blocks were freed -- no leaks are possible.
--14078--  memcheck: sanity checks: 2 cheap, 1 expensive
--14078--  memcheck: auxmaps: 113 auxmap entries (7232k, 7M) in use
--14078--  memcheck: auxmaps: 423221 searches, 826356 comparisons
--14078--  memcheck: SMs: n_issued      = 19 (304k, 0M)
--14078--  memcheck: SMs: n_deissued    = 0 (0k, 0M)
--14078--  memcheck: SMs: max_noaccess  = 524287 (8388592k, 8191M)
--14078--  memcheck: SMs: max_undefined = 0 (0k, 0M)
--14078--  memcheck: SMs: max_defined   = 138 (2208k, 2M)
--14078--  memcheck: SMs: max_non_DSM   = 19 (304k, 0M)
--14078--  memcheck: max sec V bit nodes:    0 (0k, 0M)
--14078--  memcheck: set_sec_vbits8 calls: 0 (new: 0, updates: 0)
--14078--  memcheck: max shadow mem size:   4448k, 4M
--14078-- translate:            fast SP updates identified: 904 ( 86.5%)
--14078-- translate:   generic_known SP updates identified: 82 (  7.8%)
--14078-- translate: generic_unknown SP updates identified: 59 (  5.6%)
--14078--     tt/tc: 2,904 tt lookups requiring 2,927 probes
--14078--     tt/tc: 2,904 fast-cache updates, 5 flushes
--14078--  transtab: new        1,353 (32,509 -&gt; 615,415; ratio 189:10) [0 scs]
--14078--  transtab: dumped     0 (0 -&gt; ??)
--14078--  transtab: discarded  15 (315 -&gt; ??)
--14078-- scheduler: 255,681 jumps (bb entries).
--14078-- scheduler: 2/1,810 major/minor sched events.
--14078--    sanity: 3 cheap, 1 expensive checks.
--14078--    exectx: 30,011 lists, 5 contexts (avg 0 per list)
--14078--    exectx: 5 searches, 0 full compares (0 per 1000)
--14078--    exectx: 0 cmp2, 10 cmp4, 0 cmpAll
Illegal instruction</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>471823</commentid>
    <comment_count>1</comment_count>
    <who name="Julian Seward">jseward</who>
    <bug_when>2006-09-22 00:36:43 +0000</bug_when>
    <thetext>What do cli and sti do in user-mode?  I can see the kernel might want
to use them, but in user-mode what are they for?
</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>471826</commentid>
    <comment_count>2</comment_count>
    <who name="Jeremy Fitzhardinge">jeremy</who>
    <bug_when>2006-09-22 00:43:21 +0000</bug_when>
    <thetext>It&apos;s possible to use them in usermode if the process has used iopl() get 
access to them.  But its pretty rare, and they&apos;re pretty much impossible 
to use correctly in general.  The big offender used to be the X server, 
but I don&apos;t think it does any more.

You could probably implement them as no-ops without any loss of 
generality.  (But if you did, I bet the next report will be that in/out 
are not implemented.)
</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>471829</commentid>
    <comment_count>3</comment_count>
    <who name="Yousong Mei">YousongMei</who>
    <bug_when>2006-09-22 00:48:11 +0000</bug_when>
    <thetext>In our case, we try to measure some timing and we do not want to interrupt
to happen when we measure the timing, which will skew the result.

Thanks.

At 03:36 PM 9/21/2006, Julian Seward wrote:
[bugs.kde.org quoted mail]
</thetext>
  </long_desc>
      
      

    </bug>

</bugzilla>