|
From: Christian P. <tr...@ge...> - 2005-08-24 22:20:50
|
hi, well, I just ran into this, when testing my daemon on x86 using VG 3.0 (I u= sed=20 2.4.1 before, to get some kcachegrind stats). Regards, Christian Parpart. |
|
From: Christian P. <tr...@ge...> - 2005-08-24 22:40:43
|
On Thursday 25 August 2005 01:19, Christian Parpart wrote: > hi, > > well, I just ran into this, when testing my daemon on x86 using VG 3.0 (I > used 2.4.1 before, to get some kcachegrind stats). Thanks to John Reiser, I've been able to decode it by myself :-D repz ret err... this is using VG 3.0.0 (release build)... I need to check wether thi= s=20 is *already* fixed (as I remember that repz/q ret from some time ago)... well, okay, VG from trunk from right now raises this error, too. Should I open a bug on this or is it fixed rather soon? Regards, Christian Parpart. |
|
From: Tom H. <to...@co...> - 2005-08-24 22:44:40
|
In message <200...@ge...>
Christian Parpart <tr...@ge...> wrote:
> repz ret
>
> err... this is using VG 3.0.0 (release build)... I need to check wether this
> is *already* fixed (as I remember that repz/q ret from some time ago)...
Oh, that... A bit of amd wierdness. There's a long thread about it
on an old bug somewhere.
> well, okay, VG from trunk from right now raises this error, too.
Probably. I don't expect VEX handles it.
> Should I open a bug on this or is it fixed rather soon?
Open a bug please.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Nicholas N. <nj...@cs...> - 2005-08-24 22:44:45
|
On Thu, 25 Aug 2005, Christian Parpart wrote: > repz ret > > err... this is using VG 3.0.0 (release build)... I need to check wether this > is *already* fixed (as I remember that repz/q ret from some time ago)... > > well, okay, VG from trunk from right now raises this error, too. > > Should I open a bug on this or is it fixed rather soon? Please open a bug so we have a record of it. Hopefully it will be fixed soon anyway :) N |
|
From: Christian P. <tr...@ge...> - 2005-08-24 23:29:59
|
On Thursday 25 August 2005 00:44, Nicholas Nethercote wrote: > Please open a bug so we have a record of it. =A0Hopefully it will be fixed > soon anyway :) the input form's component list still lags in a "vex" component entry :( however, assigned it to "general" [0]. Regards, Christian Parpart. [0] http://bugs.kde.org/show_bug.cgi?id=3D111451 |
|
From: John R.
|
vex x86->IR: unhandled instruction bytes: 0xF3 0xC3 0x75 0xA repz ret # 0xF3 0xC3 jnz +10 # 0x75 0x0A "repz ret" is an optimization for amd64 that happens to be equivalent to "ret" on x86. However, it is unusual for "jnz +10" to follow. Check for corruption (either by the program, or by vex for the preceding instruction) or hand-coded assembly language. -- |
|
From: Christian P. <tr...@ge...> - 2005-08-24 23:25:55
|
On Thursday 25 August 2005 00:54, John Reiser wrote: > vex x86->IR: unhandled instruction bytes: 0xF3 0xC3 0x75 0xA > > repz ret # 0xF3 0xC3 > jnz +10 # 0x75 0x0A > > "repz ret" is an optimization for amd64 that happens to be equivalent > to "ret" on x86. However, it is unusual for "jnz +10" to follow. > Check for corruption (either by the program, or by vex for the > preceding instruction) or hand-coded assembly language. it happened just right after the startup. and I didn't change any of my cod= e=20 lines for sure (it might be, that I recompiled them, can't remember, sorry). Regards, Christian Parpart. |
|
From: Julian S. <js...@ac...> - 2005-08-24 23:31:41
|
> > repz ret > > > > err... this is using VG 3.0.0 (release build)... I need to check wether > > this is *already* fixed (as I remember that repz/q ret from some time > > ago)... > > > > well, okay, VG from trunk from right now raises this error, too. > > > > Should I open a bug on this or is it fixed rather soon? This is all ancient history now :-) I fixed this a couple of weeks back on both the trunk and 3_0_BRANCH. It is bug #110671 and was fixed with vex r1332 (trunk) and r1338 (3_0_BRANCH). J |
|
From: Tom H. <to...@co...> - 2005-08-25 07:39:47
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
>> > repz ret
>> >
>> > err... this is using VG 3.0.0 (release build)... I need to check wether
>> > this is *already* fixed (as I remember that repz/q ret from some time
>> > ago)...
>> >
>> > well, okay, VG from trunk from right now raises this error, too.
>> >
>> > Should I open a bug on this or is it fixed rather soon?
>
> This is all ancient history now :-) I fixed this a couple of
> weeks back on both the trunk and 3_0_BRANCH. It is bug #110671
> and was fixed with vex r1332 (trunk) and r1338 (3_0_BRANCH).
I thought it had already come up but for some reason I couldn't see
the bug when I looked last night... I've close Christian's bug as a
duplicate now anyway.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|