[valgrind] [Bug 384230] vex x86->IR: unhandled instruction bytes: 0x67 0xE8 0xAB 0x68

[Julian Seward]

https://bugs.kde.org/show_bug.cgi?id=384230

Julian Seward  changed:

   What|Removed |Added

 CC||alexhenri...@gmail.com

--- Comment #18 from Julian Seward  ---
*** Bug 394903 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 384230] vex x86->IR: unhandled instruction bytes: 0x67 0xE8 0xAB 0x68

[Julian Seward]

https://bugs.kde.org/show_bug.cgi?id=384230

Julian Seward  changed:

   What|Removed |Added

 CC||luke...@lukeshu.com

--- Comment #17 from Julian Seward  ---
*** Bug 384156 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 384230] vex x86->IR: unhandled instruction bytes: 0x67 0xE8 0xAB 0x68

[Tom Hughes]

https://bugs.kde.org/show_bug.cgi?id=384230

--- Comment #16 from Tom Hughes  ---
Were not actually daft you know and I did check the Intel manual multiple
times. To be clear I believe this quote covers it:

"The address-size override prefix (67H) allows programs to switch between 16-
and 32-bit addressing. Either size can be the default; the prefix selects the
non-default size. Using this prefix and/or other undefined opcodes when
operands for the instruction do not reside in memory is reserved; such use may
cause unpredictable behavior."

In this case the only operand to the instruction is an immediate offset encoded
as part of the instruction, which does not "reside in memory" and as such this
use of the prefix constitutes a reserved instruction and using it may cause
"unpredictable behaviour".

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 384230] vex x86->IR: unhandled instruction bytes: 0x67 0xE8 0xAB 0x68

[Jannik Vogel]

https://bugs.kde.org/show_bug.cgi?id=384230

Jannik Vogel  changed:

   What|Removed |Added

 CC||em...@jannikvogel.de

--- Comment #15 from Jannik Vogel  ---
(In reply to John Reiser from comment #10)
> The "proper fix" is for the compiler not to generate totally wasteful code
> in the first place.
> 
> The change in valgrind correctly accommodates poor code.

To me, valgrind emulation always try to be transparent to the user. So if
something runs on the host CPU, it should run through valgrind too.
So arguing with a compiler is not the correct thing to do here.

A fix for valgrind was necessary and Toms patch gets the job done.
Wether this might be necessary for other instructions too should be tested to
make this patch more generic.

(In reply to Tom Hughes from comment #14)
> Not really - the actual bogus instruction was in ld.so which is not part of
> the code generated by that compilation.

Not 100% true. The code was also found in arch linux libGLdispatch and
libopenal. That's at least where I was affected, but other instances probably
exist too.

> So you would need to isolate the relevant file in the glibc source and try
> and create a minimised preprocessed test case from that then find a set of
> compiler options which would cause it to generate that code sequence for the
> test case.

When I originally found out about this issue, I reached out to the arch linux
openal package maintainer to figure out how packages are build.
While the openal maintainer (heftig) did not respond, other people on arch
linux IRC helped me figure out what I needed to know.

Packge https://www.archlinux.org/packages/multilib/x86_64/lib32-openal/
(version 1.18.2-1), which is affected by this bug:

- Was compiled using "gcc-multilib-7.2.0-1" (see arch repos)
- Configured using this:
https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/lib32-openal
- Systemwide compile flags can be found in makepkg.conf of the devtools helper
package

So we at least know which compiler generates such a sequence.

I've also responded in #valgrind-dev (IRC) later, when heftig responded about
why this instruction exists (following is a direct quote from heftig):

> the purpose is to make the call instruction a byte longer
> https://sourceware.org/ml/binutils/2016-05/msg00322.html
> it's the linker patching indirect -fno-plt calls (which were 6 bytes) to 
> direct calls (which are 5 bytes)
> since you have an extra byte to fill, you either need to insert a nop (which 
> would be an extra instruction) or add a pointless prefix

so this is likely done to not waste an additional nop cycle or to avoid getting
interrupts between those instructions. It might have other implications though.
So while this looks like broken code, it's actually a clever hack to make
instructions longer. As a result the patch might be incomplete as this can
probably done with other instructions too.

---

If anybody still has doubts about this patch I'd recommend checking the x86
docs to see if that says it's an illegal instruction - if not it should be
supported; if it is contact intel about it.

If you want to know more about why this sequence is generated, I'd recommend to
contact the people who worked on gcc 7.2.0

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 384230] vex x86->IR: unhandled instruction bytes: 0x67 0xE8 0xAB 0x68

[Tom Hughes]

https://bugs.kde.org/show_bug.cgi?id=384230

--- Comment #14 from Tom Hughes  ---
Not really - the actual bogus instruction was in ld.so which is not part of the
code generated by that compilation.

So you would need to isolate the relevant file in the glibc source and try and
create a minimised preprocessed test case from that then find a set of compiler
options which would cause it to generate that code sequence for the test case.

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 384230] vex x86->IR: unhandled instruction bytes: 0x67 0xE8 0xAB 0x68

[Laszlo Papp]

https://bugs.kde.org/show_bug.cgi?id=384230

--- Comment #13 from Laszlo Papp  ---
According to my opening post, "int main() { return 0; }" seems to generate it.

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 384230] vex x86->IR: unhandled instruction bytes: 0x67 0xE8 0xAB 0x68

[Tom Hughes]

https://bugs.kde.org/show_bug.cgi?id=384230

--- Comment #12 from Tom Hughes  ---
I don't believe anybody has a test case so there wouldn't be any point.

If you can come up some C that will cause the compiler to generate this
sequence then please feel free to report it.

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 384230] vex x86->IR: unhandled instruction bytes: 0x67 0xE8 0xAB 0x68

[Laszlo Papp]

https://bugs.kde.org/show_bug.cgi?id=384230

--- Comment #11 from Laszlo Papp  ---
I see; thanks. Is there an issue opened against the compiler then?

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 384230] vex x86->IR: unhandled instruction bytes: 0x67 0xE8 0xAB 0x68

[John Reiser]

https://bugs.kde.org/show_bug.cgi?id=384230

John Reiser  changed:

   What|Removed |Added

 CC||jrei...@bitwagon.com

--- Comment #10 from John Reiser  ---
(In reply to Laszlo Papp from comment #9)
> So is this now a proper solution or a workaround in the end?

The "proper fix" is for the compiler not to generate totally wasteful code in
the first place.

The change in valgrind correctly accommodates poor code.

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 384230] vex x86->IR: unhandled instruction bytes: 0x67 0xE8 0xAB 0x68

[Laszlo Papp]

https://bugs.kde.org/show_bug.cgi?id=384230

--- Comment #9 from Laszlo Papp  ---
So is this now a proper solution or a workaround in the end?

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 384230] vex x86->IR: unhandled instruction bytes: 0x67 0xE8 0xAB 0x68

[Tom Hughes]

https://bugs.kde.org/show_bug.cgi?id=384230

Tom Hughes  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #8 from Tom Hughes  ---
Committed as fb6157165bb46e9f5e8c4d5fb3287306fc2453b8.

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 384230] vex x86->IR: unhandled instruction bytes: 0x67 0xE8 0xAB 0x68

[Krzysztof Kundzicz]

https://bugs.kde.org/show_bug.cgi?id=384230

Krzysztof Kundzicz  changed:

   What|Removed |Added

 CC||athantor+kdeb...@athi.pl

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 384230] vex x86->IR: unhandled instruction bytes: 0x67 0xE8 0xAB 0x68

[Tom Hughes]

https://bugs.kde.org/show_bug.cgi?id=384230

Tom Hughes  changed:

   What|Removed |Added

 CC||sdel...@sdelang.fr

--- Comment #7 from Tom Hughes  ---
*** Bug 388407 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 384230] vex x86->IR: unhandled instruction bytes: 0x67 0xE8 0xAB 0x68

[Tom Hughes]

https://bugs.kde.org/show_bug.cgi?id=384230

--- Comment #6 from Tom Hughes  ---
Because we still don't really understand what that instruction means - that
patch is just a best guess at how to decode it.

If that patch is correct then the prefix is redundant in which case why is the
compiler generating it? Is there some subtle hidden meaning that we are unaware
of and which we need to emulate?

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 384230] vex x86->IR: unhandled instruction bytes: 0x67 0xE8 0xAB 0x68

[Steve Folta]

https://bugs.kde.org/show_bug.cgi?id=384230

Steve Folta  changed:

   What|Removed |Added

 CC||st...@folta.net

--- Comment #5 from Steve Folta  ---
I had the same problem when using the ifstream constructor, ONLY when using
"-m32".  The patch (107639) does fix it.  (However, the bug as reported -- on
dl_main() with a super-minimal main() -- did not occur for me.)

Pardon my ignorance, but why isn't that patch in Git already?

Here's my test case:

$ cat main.cpp
#include 


int main(int argc, char* argv[])
{
std::ifstream file(argv[1], std::ios_base::in);

return 0;
}


$ cat Makefile
test: main.cpp
g++ -g -m32 -o $@ $^

$ valgrind test test.txt
==7628== Memcheck, a memory error detector
==7628== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==7628== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==7628== Command: test test.txt
==7628==
vex x86->IR: unhandled instruction bytes: 0x67 0xE8 0x7D 0xFF
==7628== valgrind: Unrecognised instruction at address 0x48eb53d.
==7628==at 0x48EB53D: std::locale::locale() (locale_init.cc:250)
==7628==by 0x4940A26: basic_ios (basic_ios.h:462)
==7628==by 0x4940A26: std::basic_ifstream::basic_ifstream(char const*, std::_Ios_Openmode) (fstream:496)
==7628==by 0x1086B0: main (main.cpp:6)
==7628== Your program just tried to execute an instruction that Valgrind
==7628== did not recognise.  There are two possible reasons for this.
==7628== 1. Your program has a bug and erroneously jumped to a non-code
==7628==location.  If you are running Memcheck and you just saw a
==7628==warning about a bad jump, it's probably your program's fault.
==7628== 2. The instruction is legitimate but Valgrind doesn't handle it,
==7628==i.e. it's Valgrind's fault.  If you think this is the case or
==7628==you are not sure, please let us know and we'll try to fix it.
==7628== Either way, Valgrind will now raise a SIGILL signal which will
==7628== probably kill your program.
==7628==
==7628== Process terminating with default action of signal 4 (SIGILL): dumping
core
==7628==  Illegal opcode at address 0x48EB53D
==7628==at 0x48EB53D: std::locale::locale() (locale_init.cc:250)
==7628==by 0x4940A26: basic_ios (basic_ios.h:462)
==7628==by 0x4940A26: std::basic_ifstream::basic_ifstream(char const*, std::_Ios_Openmode) (fstream:496)
==7628==by 0x1086B0: main (main.cpp:6)
==7628==
==7628== HEAP SUMMARY:
==7628== in use at exit: 0 bytes in 0 blocks
==7628==   total heap usage: 1 allocs, 1 frees, 18,944 bytes allocated
==7628==
==7628== All heap blocks were freed -- no leaks are possible
==7628==
==7628== For counts of detected and suppressed errors, rerun with: -v
==7628== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Illegal instruction (core dumped)

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 384230] vex x86->IR: unhandled instruction bytes: 0x67 0xE8 0xAB 0x68

[Tom Hughes]

https://bugs.kde.org/show_bug.cgi?id=384230

Tom Hughes  changed:

   What|Removed |Added

 CC||hartb...@gmail.com

--- Comment #4 from Tom Hughes  ---
*** Bug 386115 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 384230] vex x86->IR: unhandled instruction bytes: 0x67 0xE8 0xAB 0x68

[Laszlo Papp]

https://bugs.kde.org/show_bug.cgi?id=384230

--- Comment #3 from Laszlo Papp  ---
Yes, thank you so much for the quick replies and work.

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 384230] vex x86->IR: unhandled instruction bytes: 0x67 0xE8 0xAB 0x68

[Tom Hughes]

https://bugs.kde.org/show_bug.cgi?id=384230

Tom Hughes  changed:

   What|Removed |Added

 Attachment #107621|0   |1
is obsolete||

--- Comment #2 from Tom Hughes  ---
Created attachment 107639
  --> https://bugs.kde.org/attachment.cgi?id=107639=edit
Patch to ignore addr16 prefix on relative call

So it seems that this isn't actually (as we first thought) a relative call with
a 16 bit offset but rather is still a 32 bit offset but just with an
(apparently redundant) addr16 prefix.

This patch just ignores that prefix and has been confirmed to fix the problem.

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 384230] vex x86->IR: unhandled instruction bytes: 0x67 0xE8 0xAB 0x68

[Tom Hughes]

https://bugs.kde.org/show_bug.cgi?id=384230

Tom Hughes  changed:

   What|Removed |Added

 CC||t...@compton.nu

--- Comment #1 from Tom Hughes  ---
Created attachment 107621
  --> https://bugs.kde.org/attachment.cgi?id=107621=edit
Patch to implement "addr16 call" aka "call rel16"

Try building valgrind with this patch applied and see if that helps...

-- 
You are receiving this mail because:
You are watching all bug changes.