2017-09-01 3 views
0

Nous sommes en train de déboguer des problèmes de mémoire avec notre grande application ancienne et nous aimerions utiliser Valgrind pour le traquer. L'application utilise le ACE/TAO CORBA library cependant, Valgrind se plaint des instructions "vex" illégales dans la bibliothèque.gcc/C++ Désactiver la génération d'instructions vex

==29992== Memcheck, a memory error detector 
==29992== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. 
==29992== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info 
==29992== Command: DvMain 
==29992== 
DvMain. Version 6.0 Build 38B16 
vex x86->IR: unhandled instruction bytes: 0xC4 0xE2 0x7B 0xF7 
==29992== valgrind: Unrecognised instruction at address 0x5f37a4b. 
==29992== at 0x5F37A4B: ACE_Select_Reactor_Impl::bit_ops(int, unsigned long, ACE_Select_Reactor_Handle_Set&, int) (in /usr/local/dvstation/lib3p/ACE/libACE.so.6.2.7) 

In another SO question, VTT a suggéré de désactiver les instructions AVX -mno-avx, qui a travaillé sur certaines choses. Cependant, ont toujours des problèmes.

J'ai essayé -mno-sse2avx -mno-avx -mno-sse4.1 -mno-sse4.2 -mno-sse4 -mno-sse4a mais Valgrind se plaint toujours des instructions de VEX dans ::bit_ops() (Si vous êtes intéressé, bit_ops est défini sur line 956 of this file)

Comment puis-je désactiver complètement la génération d'instructions VEX pour que je puisse utiliser Valgrind déboguer?

plate-forme est de 32 bits CentOS 6, g ++ 4.9.4

(s'il vous plaît ne suggèrent pas de passer à 64 bits Ce n'est pas une option avec ce produit.)

Référence:

compiler ligne pour le fichier incriminé:

/usr/local/gcc-4.9.4/bin/c++4.9 -mno-sse2avx -fvisibility=hidden 
-fvisibility-inlines-hidden -fdiagnostics-color=auto 
-mno-avx -mno-sse4.1 -mno-sse4.2 -mno-sse4 -mno-sse4a 
-O3 -march=native -pthread -fno-strict-aliasing 
-Wall -W -Wpointer-arith -pipe -D_GNU_SOURCE 
-c -fPIC -o .shobj/Select_Reactor_Base.o Select_Reactor_Base.cpp 

Répondre

0

VEX est assez nouveau. En utilisant une ancienne architecture, par ex. -march=pentium4 désactive le codage d'instructions VEX, mais vous conservez SSE2.

+0

@PaulFloyd: Le terme est surchargé, mais ici, il signifie clairement le codage VEX x86. Vous pouvez le voir dans "instruction non gérée octets:' 0xC4 0xE2 0x7B 0xF7' ". 0xC4 est le préfixe VEX x86. – MSalters

+0

Je ne connaissais pas le préfixe d'opcode VEX. Du côté de Valgrind, le message n'est pas lié à cela. Dans VEX/priv/guest_x86_toIR.c, il y a '/ * Toutes les erreurs de décodage se terminent ici. */vex_printf ("vex x86-> IR: instruction non gérée octets:" ' –

+0

@PaulFloyd: Le _cause_ de l'échec du décodage est l'instruction" 0xC4 0xE2 0x7B 0xF7 ", qui est une instruction encodée en x86 VEX que Valgrind ne parvient pas à analyser .En utilisant '-march = pentium4', GCC ne générera pas cette instruction' 0xC4', évitant l'échec du décodage. – MSalters

1

peut-être que vous pouvez utiliser valgrind 3,12 DTS de la place, sous la forme du paquet devtoolset-6-valgrind?

support pour les instructions de AVX2 a été ajouté à valgrind 3.9, vous pourriez éviter de recompiler votre logiciel.

+0

Le Centos 6 32 bits ne prend en charge que les devtools-3. Les notes de version pour valgrind 3.9 disent "Support des instructions Intel AVX2, disponible uniquement sur 64 bits" ... – Danny

-1

VEX est la représentation de la machine abstraite de Valgrind. C'est une partie fondamentale de Valgrind et vous ne pouvez pas l'éteindre. Vous devez soit dire au compilateur d'émettre du code machine que votre version de Valgrind comprend, soit effectuer une mise à niveau vers une version plus récente de Valgrind qui comprend AVX.

AVX dates from about 2011 alors que la version de Valgrind que vous utilisez a été publiée en septembre 2012 et qu'elle n'a probablement pas ajouté le support AVX. Confusingly, ces extensions utilisent également un "VEX" prefix. Dans ce cas, le message "vex x86-> IR" de Valgrind fait référence au VEX de Valgrind et non au préfixe AVX VEX.

+0

"Vous devez soit dire au compilateur d'émettre du code machine que votre version de Valgrind comprend" n'est pas tant une réponse qu'une reformulation de la question. Le compilateur est GCC; _how_ obtenez-vous que GCC émette du code machine x86 sans utiliser x86 VEX? – MSalters

+0

Cela a déjà été répondu. Cependant si un futur lecteur a une erreur comme "vex x86-> IR: instruction non gérée octets 0xf 0x5" et ils trouvent cette question/réponse alors la désactivation de la génération du compilateur VEX/AVX n'est pas susceptible d'aider. –