Bug 227551 - vex amd64->IR: unhandled instruction bytes: 0xF3 0x48 0xF 0xBD 0xFF 0xB0
Summary: vex amd64->IR: unhandled instruction bytes: 0xF3 0x48 0xF 0xBD 0xFF 0xB0
Status: RESOLVED DUPLICATE of bug 212335
Alias: None
Product: valgrind
Classification: Developer tools
Component: vex (show other bugs)
Version: unspecified
Platform: Gentoo Packages Linux
: NOR crash
Target Milestone: ---
Assignee: Julian Seward
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-02-18 19:01 UTC by Bernd Buschinski
Modified: 2010-02-21 19:07 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Bernd Buschinski 2010-02-18 19:01:45 UTC
Version:           3.6.0-r11050 (using KDE 4.4.0)
Compiler:          gcc-4.4.3 
OS:                Linux
Installed from:    Gentoo Packages

On my AMD Phenom X4 9600 and Phenom II X4 945, if Qt 4.5 or 4.6 (didn't try with Qt-4.4) is build with glib support, I can't valgrind any kde4 app.
If Qt is build without glib support everything works fine.

vex amd64->IR: unhandled instruction bytes: 0xF3 0x48 0xF 0xBD 0xFF 0xB0

 Process terminating with default action of signal 4 (SIGILL)             
  Illegal opcode at address 0xD513BCA                                     
    at 0xD513BCA: T.128 (gutils.h:358)                                    
    by 0xD513C84: slab_allocator_alloc_chunk (gslice.c:1005)              
    by 0xD514D22: g_slice_alloc (gslice.c:661)                            
    by 0xD4D189C: g_array_sized_new (garray.c:87)                         
    by 0xD520228: g_static_private_set (gthread.c:451)                    
    by 0xD4DF46A: g_get_filename_charsets (gconvert.c:1199)               
    by 0xD4DF4ED: _g_convert_thread_init (gconvert.c:1304)                
    by 0xD520499: g_thread_init_glib (gthread.c:165)                      
    by 0x887787E: QEventDispatcherGlibPrivate::QEventDispatcherGlibPrivate(_GMainContext*) (qeventdispatcher_glib.cpp:297)
    by 0x9281F8E: QGuiEventDispatcherGlibPrivate::QGuiEventDispatcherGlibPrivate() (qguieventdispatcher_glib.cpp:171)     
    by 0x928207E: QGuiEventDispatcherGlib::QGuiEventDispatcherGlib(QObject*) (qguieventdispatcher_glib.cpp:186)           
    by 0x92484D2: QApplicationPrivate::createEventDispatcher() (qapplication_x11.cpp:596)


CFLAGS="-march=amdfam10 -O2 -pipe -fomit-frame-pointer -g"
CHOST="x86_64-pc-linux-gnu"
valgrind-svn-r11050
Comment 1 Bernd Buschinski 2010-02-18 19:07:45 UTC
gutils.h:358 is

((GLIB_SIZEOF_LONG * 8 - 1) ^ __builtin_clzl(number)) + 1 : 1;

guess it is a problem with __builtin_clzl(number)) and how gcc/AMD handles it?
Comment 2 Bernd Buschinski 2010-02-18 20:02:36 UTC
I build a small standalone testcase

inline int number(unsigned long a)
{
    return true ?
       ((8 * 8 - 1) ^ __builtin_clzl(a)) + 1 : 1;
}

but valgrind works fine there, so I guess it is not __builtin_clzl
Comment 3 Tom Hughes 2010-02-18 20:18:02 UTC
There's no need for lots of complicated diagnostics - the error message is sufficient to tell us what needs to be done.

The instruction here (after prefixed are removed) is 0x0F 0xBD which decodes as:

BSR Gv, Ev

We do have support for that instruction, but we reject it if it has an F3 prefix like this one does.

As far as I can see in the instruction set manual it is indeed invalid to have a repeat prefix like F3 on this instruction.
Comment 4 Bernd Buschinski 2010-02-18 21:44:31 UTC
Sorry but I don't see why F3 prefix is invalid in this case

maybe I interpreted it wrong but according too
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24594.pdf
page 183 (LZCNT Count Leading Zeros)

Everything seems to be fine
Comment 5 Tom Hughes 2010-02-18 22:08:27 UTC
I was using too old a copy of the manual, which means that must be a fairly new instruction. The description also clearly says:

"Software MUST check the CPUID bit once per program or library initialization before using the LZCNT instruction, or inconsistent behavior may result.

Which your program presumably isn't don't as valgrind will not be asserting that bit in the CPUID flags.

The reason that it's not safe to use without checking the CPU is that on old processors the F3 prefix was probably ignored, so the instruction would execute as BSR rather than faulting if run on an old processor.
Comment 6 Julian Seward 2010-02-21 19:07:59 UTC

*** This bug has been marked as a duplicate of bug 212335 ***