[valgrind] [Bug 354274] arm: unhandled instruction: 0xEBAD 0x0AC1 (sub.w sl, sp, r1, lsl #3)
https://bugs.kde.org/show_bug.cgi?id=354274 Julian Seward changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #1 from Julian Seward --- Committed as vex r3257, and will be in 3.12.0. Thanks for the patch. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 360571] Error about the Android Runtime reading below the stack pointer on ARM
https://bugs.kde.org/show_bug.cgi?id=360571 --- Comment #8 from Julian Seward --- Created attachment 101477 --> https://bugs.kde.org/attachment.cgi?id=101477&action=edit A simple test program. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 360571] Error about the Android Runtime reading below the stack pointer on ARM
https://bugs.kde.org/show_bug.cgi?id=360571 --- Comment #9 from Julian Seward --- Anton, can you perhaps try this on aarch64 ? Would this work for you? (Apologies .. there's one line in the test program you'll have to change.) -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 360571] Error about the Android Runtime reading below the stack pointer on ARM
https://bugs.kde.org/show_bug.cgi?id=360571 --- Comment #7 from Julian Seward --- Created attachment 101476 --> https://bugs.kde.org/attachment.cgi?id=101476&action=edit Proposed fix (lacks documentation, but seems to work) For example, to keep the test program (next attachment) happy: ./vg-in-place --ignore-range-below-sp=8192-8189 ./access_below_sp Note that the first specified offset must be larger than the second, so as to imply a non-wraparound address range. This is because they are really negative offsets relative to the stack pointer. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 369854] Valgrind reports an Invalid Read in __intel_new_memcpy
https://bugs.kde.org/show_bug.cgi?id=369854 --- Comment #2 from Julian Seward --- What version of Valgrind are you using here? Can you re-run with the extra flag --partial-loads-ok=yes ? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 369439] S390x: Unhandled insns RISBLG/RISBHG and LDE/LDER
https://bugs.kde.org/show_bug.cgi?id=369439 Julian Seward changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 370028] Reduce the number of compiler warnings on MIPS platforms
https://bugs.kde.org/show_bug.cgi?id=370028 --- Comment #9 from Julian Seward --- This feels to me like hiding misalignment problems. I'd prefer to remove misaligned accesses where possible. Building with --enable-usban at least makes it possible to see, on any platform, where the run-time misaligned accesses are. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 370398] trunk/VEX/priv/guest_x86_helpers.c:1693: strange expression ?
https://bugs.kde.org/show_bug.cgi?id=370398 Julian Seward changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 370398] trunk/VEX/priv/guest_x86_helpers.c:1693: strange expression ?
https://bugs.kde.org/show_bug.cgi?id=370398 --- Comment #1 from Julian Seward --- The code is as intended. Compare with line 1688 (a few lines up) and you'll see why it is written how it is. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 352197] mips32: mmap2() not wrapped correctly for page size > 4096
https://bugs.kde.org/show_bug.cgi?id=352197 --- Comment #4 from Julian Seward --- Petar: Duncan: the patch fixes only the mips32 case. Is the mips64 path correct, or does that also need to be fixed? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 365327] Support macOS Sierra (10.12)
https://bugs.kde.org/show_bug.cgi?id=365327 --- Comment #5 from Julian Seward --- (In reply to Rhys Kidd from comment #4) > Preliminary support added in r15976. Merged to 3_12_BRANCH in r16071. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 360571] Error about the Android Runtime reading below the stack pointer on ARM
https://bugs.kde.org/show_bug.cgi?id=360571 --- Comment #11 from Julian Seward --- Committed on trunk, r16073. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 368823] run_a_thread_NORETURN assembly code typo for VGP_arm64_linux target
https://bugs.kde.org/show_bug.cgi?id=368823 Julian Seward changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #1 from Julian Seward --- Committed, r16074. Thanks for the patch. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 368120] x86_linux asm _start functions do not keep 16-byte aligned stack pointer
https://bugs.kde.org/show_bug.cgi?id=368120 Julian Seward changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Julian Seward --- Committed, r16075. Thanks for the patch. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 360571] Error about the Android Runtime reading below the stack pointer on ARM
https://bugs.kde.org/show_bug.cgi?id=360571 Julian Seward changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 369723] __builtin_longjmp not supported in clang/llvm on Android arm64 target
https://bugs.kde.org/show_bug.cgi?id=369723
--- Comment #2 from Julian Seward ---
(In reply to chh from comment #0)
> Suggested fix, to add VG_MINIMAL_SETJMP and VG_MINIMAL_LONGJMP for
> VGP_arm64_linux:
> [..patch follows..]
Thank you for looking into this. This looks like a good solution to
me. But I did not understand the patch. All the other
implementations of VG_MINIMAL_{SET,LONG}JMP save and restore all the
integer registers. This patch definitely does not do that. Can you
fix it? A good place to start is by copying the ppc32_linux case.
Also .. when attaching patches, please attach them as a separate
file, not as an in-line comment. Getting a usable patch out of an
in-line comment is very difficult (try it!)
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 356112] mips: replace addi with addiu
https://bugs.kde.org/show_bug.cgi?id=356112 Julian Seward changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 366079] FPXX Support for MIPS32 Valgrind
https://bugs.kde.org/show_bug.cgi?id=366079 Julian Seward changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 352767] Wine/valgrind: Warning: noted but unhandled ioctl 0x5307 with no size/direction hints. (CDROMSTOP)
https://bugs.kde.org/show_bug.cgi?id=352767 --- Comment #3 from Julian Seward --- (In reply to austinengl...@gmail.com from comment #2) > Not currently, but I took a quick look. There are several more syscalls that > wine uses in the source that are bsd/osx specific, but I can't easily test. > Should I stub those / put fixme's, or just fix linux/generic? Or only fix > the two that currently have bugs? Sorry for slow response. I'd suggest you only fix the cases you can actually test, since I prefer not to have unverified code in the tree. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 355803] Add Lustre's IOC_MDC_GETFILESTRIPE ioctl
https://bugs.kde.org/show_bug.cgi?id=355803 --- Comment #8 from Julian Seward --- Frank, ping me when this hits the mainline kernel. Then we can take the patch in V. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 367942] Segfault vgPlain_do_sys_sigaction (m_signals.c:1138)
https://bugs.kde.org/show_bug.cgi?id=367942 --- Comment #1 from Julian Seward --- There have been commits to the trunk which make V more robust to bad parameters to rt_sigaction and friends. Can you re-try with the trunk, or with the upcoming 3.12.0 release? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 366817] VALGRIND_MEMPOOL_CHANGE has a performance bug
https://bugs.kde.org/show_bug.cgi?id=366817 --- Comment #2 from Julian Seward --- ping? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 351282] valgrind 3.10.1 MIPS softfloat build broken with GCC 4.9.3 / binutils 2.25.1
https://bugs.kde.org/show_bug.cgi?id=351282 Julian Seward changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Julian Seward --- Closing. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 365208] valgrind stuck after redirecting "memcpy"
https://bugs.kde.org/show_bug.cgi?id=365208 --- Comment #7 from Julian Seward --- What CPU are you running on here? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 358213] helgrind/drd bar_bad testcase hangs with new glibc pthread barrier implementation
https://bugs.kde.org/show_bug.cgi?id=358213 --- Comment #7 from Julian Seward --- Should we close this now? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 352197] mips32: mmap2() not wrapped correctly for page size > 4096
https://bugs.kde.org/show_bug.cgi?id=352197 Julian Seward changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 369264] Fedora 24 i686 and vex x86->IR: unhandled instruction bytes: 0xC5 0xF8 0x10 0x3
https://bugs.kde.org/show_bug.cgi?id=369264 Julian Seward changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #2 from Julian Seward --- On 32-bit x86, only SSSE3 and below are supported. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 357932] vex amd64->IR: unhandled instruction bytes: 0xF2 0x49 0xF 0x5D and 0xF2 0x49 0xF 0x5F
https://bugs.kde.org/show_bug.cgi?id=357932 Julian Seward changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #7 from Julian Seward --- Committed, vex r3274. Thanks for the patch. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 357059] x86: SSE cvtpi2ps with memory source does transition to MMX state
https://bugs.kde.org/show_bug.cgi?id=357059 Julian Seward changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Julian Seward --- Fixed as described in comment #3. Janne, thanks for spotting this. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 368419] Perf Events ioctls not implemented
https://bugs.kde.org/show_bug.cgi?id=368419 Julian Seward changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Julian Seward --- Committed, r16077. Thanks for the patch. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 359645] [patch] "You need libc6-dbg" help message could be more helpful with 32-bit target on-64-bit arch
https://bugs.kde.org/show_bug.cgi?id=359645 Julian Seward changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #1 from Julian Seward --- Committed, r16078. Thanks for the patch. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 368507] valgrind throws std::bad_alloc on memory allocations larger than 34255421416 bytes
https://bugs.kde.org/show_bug.cgi?id=368507 --- Comment #5 from Julian Seward --- I had hoped to do this for 3.12.0, but after looking at the #ifdef swamp in VG_(am_startup) that sets aspacem_maxAddr, I think it is too risky, because of the number of different cases that need to be verified. So I'd propose to leave it till after the release. The number of users that this will affect is tiny and those that really need it in 3.12.x can cherry pick the trunk commit into their own custom 3.12.x build, once we fix it on the trunk. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 351632] UNKNOWN fcntl 97 on OS X 10.11
https://bugs.kde.org/show_bug.cgi?id=351632 Julian Seward changed: What|Removed |Added CC||jsew...@acm.org --- Comment #4 from Julian Seward --- Rhys, what is the status of this now? Can it be resolved more fully, per comment 1 ? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 357734] "unhandled instruction 0x1AC12D8C" for ARM64/AARCH64
https://bugs.kde.org/show_bug.cgi?id=357734 Julian Seward changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 357928] valgrind: m_mallocfree.c:303 (get_bszB_as_is): Assertion 'bszB_lo == bszB_hi' failed
https://bugs.kde.org/show_bug.cgi?id=357928 Julian Seward changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 358620] ARM: unhandled syscall: 357
https://bugs.kde.org/show_bug.cgi?id=358620 --- Comment #3 from Julian Seward --- This is with 3.7.0, which is really old now. Can you try again with 3.11.0 or better with the current SVN trunk? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 359524] bt, btc, btr and bts instruction improperly translated by VEX on x86-64
https://bugs.kde.org/show_bug.cgi?id=359524 --- Comment #1 from Julian Seward --- What you're seeing is the result of a kludge, in which btq for a register operand is implemented by pushing the argument on the (guest) stack temporarily, and then executing the same IR as for btq with a memory operand. Have a look at the relevant bits of guest_amd64_toIR.c. I'm sure it's documented there. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 359524] bt, btc, btr and bts instruction improperly translated by VEX on x86-64
https://bugs.kde.org/show_bug.cgi?id=359524 --- Comment #2 from Julian Seward --- Honestly .. do you think any large program would actually run properly on Valgrind if these instructions had really been misimplemented? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 359524] bt, btc, btr and bts instruction improperly translated by VEX on x86-64
https://bugs.kde.org/show_bug.cgi?id=359524 Julian Seward changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 359767] Valgrind does not support the IBM POWER ISA 3.0 instructions
https://bugs.kde.org/show_bug.cgi?id=359767 Julian Seward changed: What|Removed |Added Status|CLOSED |RESOLVED -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 359950] Wrong result comparing doubles on x87
https://bugs.kde.org/show_bug.cgi?id=359950 --- Comment #5 from Julian Seward --- (In reply to Tom Hughes from comment #3) > Although I'm not clear if that is what has happened here (and this should > only happen when not running under valgrind) that's not actually true with > x87 because if the compiler chooses to move one of the values from the FP > stack to memory in the middle of the comparisons for any reason it will get > converted from 80 bit to 64 bit and it's value will change... As a side note .. no .. x87 spills/reloads are done with 80-bit loads/stores, exactly to avoid the situation that the values computed depend on the specifics of register allocation. That said .. I'm not really clear what's going on here. It might be some kind of precision problem, given that there are only really 53 mantissa bits available because V simulates 80 bit registers using normal double-precision values. It would require further investigation. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 361615] Inconsistent termination when an instrumented multithreaded process is terminated by signal
https://bugs.kde.org/show_bug.cgi?id=361615 --- Comment #2 from Julian Seward --- Do you have a small test case which demonstrates that Valgrind's behaviour at present, differs from when the program is run "natively" ? I'd be happier about this if you have something directly that demonstrates that V's behaviour differs from that of the kernel, in this respect. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 362935] [AsusWRT] Assertion 'sizeof(TTEntryC) <= 88' failed
https://bugs.kde.org/show_bug.cgi?id=362935 --- Comment #1 from Julian Seward --- valgrind: m_transtab.c:2459 (vgPlain_init_tt_tc): Assertion 'sizeof(TTEntryC) <= 88' failed was a temporary problem; I am sure it has now been fixed. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 364435] Crash - Unrecognized instruction for Arm64 LDPSW
https://bugs.kde.org/show_bug.cgi?id=364435 Julian Seward changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Julian Seward --- This has been fixed in the trunk now. *** This bug has been marked as a duplicate of bug 360425 *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 360425] arm64 unsupported instruction ldpsw
https://bugs.kde.org/show_bug.cgi?id=360425 Julian Seward changed: What|Removed |Added CC||jh...@codeaurora.org --- Comment #8 from Julian Seward --- *** Bug 364435 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 359950] Wrong result comparing doubles on x87
https://bugs.kde.org/show_bug.cgi?id=359950
--- Comment #7 from Julian Seward ---
(In reply to Tom Hughes from comment #6)
> Note that I didn't mean spills/reloads that valgrind's internal
> implementation does, but rather any spills/reloads that the original
> compiler generated.
Yes -- that's also what I meant.
> Are you saying that gcc instead allocates an 80 bit temporary
> location for the spill to avoid losing precision?
Well I *thought* that was the case, but it seems I am wrong. Using
this spill-inducing loop
int main ( int argc, char** argv )
{
double a, b, c, d, e, f, g, h;
a=b=c=d=e=f=g=h=1.2345;
int i;
for (i = 0; i < 1234 * argc; i++) {
a += i * 1.2;
b += a * 1.3;
c += d / 1.4;
d += e - 1.5;
e += f + 1.6;
f += g - 1.7;
g += h * 1.8;
h += a - (b*c) + (d*e*f/g);
}
return (a-b-c-d-e-f-g-h > 987.345 ? 1 : 0);
}
I get the assembly (for the loop body) below, which uses 64-bit loads
and stores (fstpl -16(%ebp), fmull -16(%ebp), etc) with gcc6 -m32 -O2.
To get 80-bit accesses (fstpt, fldt) I need to change the declaration
to be "long double".
Ah well. Live and learn. Now I am wondering why I believed gcc did
always do 80-bit spills/reloads.
.L3:
movl%eax, -28(%ebp)
addl$1, %eax
fildl -28(%ebp)
cmpl%edx, %eax
fmull .LC1
faddp %st, %st(1)
fldl.LC2
fmul%st(1), %st
faddl -24(%ebp)
fld %st(0)
fstpl -24(%ebp)
fldl.LC3
fdivr %st(7), %st
faddl -16(%ebp)
fstpl -16(%ebp)
fld %st(3)
fsubs .LC4
faddp %st, %st(7)
fldl.LC5
fadd%st(5), %st
faddp %st, %st(4)
fldl.LC6
fsubr %st(6), %st
faddp %st, %st(5)
fldl.LC7
fmul%st(3), %st
faddp %st, %st(6)
fld %st(6)
fmul%st(4), %st
fmul%st(5), %st
fdiv%st(6), %st
fxch%st(1)
fmull -16(%ebp)
fsubr %st(2), %st
faddp %st, %st(1)
faddp %st, %st(2)
jne .L3
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 351726] vex amd64->IR: unhandled instruction bytes: 0xC5 0xF3 0xC2 0x15 0xEB 0x7C 0x2 0x0
https://bugs.kde.org/show_bug.cgi?id=351726
--- Comment #1 from Julian Seward ---
I can't reproduce this on the trunk with the test program before, and I can't
find any commit in the past 4 years which might have fixed such a bug. So
I am mystified. Which version of valgrind was this?
int main ( void )
{
__asm__ __volatile__("vcmpnlt_uqsd 0x0(%rip),%xmm1,%xmm2");
return 0;
}
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 364948] Add IBM ISA 3.0 support, patch set 5
https://bugs.kde.org/show_bug.cgi?id=364948 --- Comment #3 from Julian Seward --- (In reply to Carl Love from comment #2) > expected output files are rather large, total size is 33MBytes. 33 MB is pretty large. That space will be in the distro tarballs for ever more and also on the SVN server. Is it possible to make this a bit smaller, without losing test coverage? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 364948] Add IBM ISA 3.0 support, patch set 5
https://bugs.kde.org/show_bug.cgi?id=364948
--- Comment #4 from Julian Seward ---
(In reply to Carl Love from comment #1)
> Created attachment 99775 [details]
> Patch 5 of 5 to add VEX support for Power ISA 3.0 instructions
I have a number of concerns here, but nothing that can't be relatively
easily fixed. They fall into 5 areas:
[1] naming and possible duplication of new IROps
[2] front end: duplication of IR trees (the IRExpr* vs IRTemp thing)
[3] front end: generation of excessively verbose IR for some vector insns
[4] misc other correctness comments/queries
[5] various typos in comments
To go through them in order:
-- [1] naming and possible duplication of new IROps --
diff --git a/VEX/pub/libvex_ir.h b/VEX/pub/libvex_ir.h
+ Iop_MulAddF128,// (A * B) + C
+ Iop_MulSubF128,// (A * B) - C
+ Iop_NegMulAddF128, // -((A * B) + C)
+ Iop_NegMulSubF128, // -((A * B) + C)
Call these, respectively: MAddF128, MSubF128, NegMAddF128,
NegMSubF128, so as to be consistent with the 32/64 bit variants
+ Iop_ConvI64UtoF128, /* signed I64 -> F128 */
+ Iop_ConvI64StoF128, /* signed I64 -> F128 */
+ Iop_ConvF64toF128, /* F64 -> F128 */
+ Iop_ConvF128toF64, /* IRRoundingMode(I32) x F128 -> F64*/
+ Iop_ConvF128toF32, /* IRRoundingMode(I32) x F128 -> F32*/
Remove the leading Conv (eg Iop_I64UtoF128), so as to make them
consistent with other conversion operations.
+ /* Conversion signed 32-bit value to signed BCD 128-bit */
+ Iop_I128StoBCD128,
+
+ /* Conversion signed BCD 128-bit to signed 32-bit value */
+ Iop_BCD128toI128S,
The comments don't seem to match the names. Is the integer value
32 bits or 128 bits?
+ /* -- Vector to/from half conversion -- */
+ Iop_F16x4toF32x4, Iop_F32x4toF16x4, Iop_F64x2toF16x2, Iop_F16x2toF64x2,
You only need one lane specifier here, so as to be consistent with
other ops:
F16toF32x4, F32toF16x4, F64toF16x2, F16toF64x2
and in fact the first two already seem to exist. Are these different?
[2] front end: duplication of IR trees (the IRExpr* vs IRTemp thing)
+static void putC ( IRExpr* e )
+static IRExpr * create_FPCC( IRExpr *NaN, IRExpr *inf,
+ IRExpr *zero, IRExpr *norm,
+ IRExpr *dnorm, IRExpr *pos,
+ IRExpr *neg ) {
+static IRExpr * create_C( IRExpr *NaN, IRExpr *zero,
+ IRExpr *dnorm, IRExpr *pos,
+ IRExpr *neg ) {
These functions all use their input trees more than once and so will
duplicate them and the computations done by them. Please change them so
that the passed arguments are IRTemps instead.
There may be more such functions -- I am not sure if this is all of
them.
[3] front end:
generation of excessively verbose IR for some vector insns
+ case 28: // vctzb, Vector Count Trailing Zeros Byte
Too complex; use a vector IRop
+ case 29: // vctzh, Vector Count Trailing Zeros Halfword
Ditto
+ case 30: // vctzw, Vector Count Trailing Zeros Word
Ditto
+ case 31: // vctzd, Vector Count Trailing Zeros Halfword
Ditto
For the above cases (28/29/30/31), make yourself a set of vector IROps
to do this:
Iop_Ctz{8x16, 16x8, 32x4}
See existing ops Iop_Clz8x16, Iop_Clz16x8, Iop_Clz32x4 as an example
+ case 0: // bcdctsq. (Decimal Convert to Signed Quadword VX-form)
+ /* Check each of the nibbles for a valid digit 0 to 9 */
+ inv_flag[0] = newTemp( Ity_I1 );
+ assign( inv_flag[0], mkU1( 0 ) );
Didn't you do a C helper function for this in the previous patch?
This generates terribly verbose code.
-- [4] misc other correctness comments/queries --
+static
+Bool FPU_rounding_mode_isOdd (IRExpr* mode) {
+ /* If the rounding mode is set to odd, the the expr must be a constant U8
+* value equal to 8. Otherwise, it must be a bin op expressiong that
+* calculates the value.
+*/
+
+ if (mode->tag != Iex_Const)
+ return False;
+
+ vassert(mode->Iex.Const.con->tag == Ico_U32);
+ if (mode->Iex.Const.con->Ico.U8 == 0x8)
+ return True;
+
+ vex_printf("ERROR: FPU_rounding_mode_isOdd(), constant not equal to
expected value\n");
+ return False;
+}
Doesn't seem right to me. What happens if mode isn't an Iex_Const?
Do you really want to just return False? Shouldn't the system assert
if that happens?
+++ b/memcheck/mc_translate.c
+#if !(defined(VGA_ppc64be) || defined(VGA_ppc64le))
tl_assert(ty != Ity_I128);
+#endif
Don't make this conditional
-- [5] various typos in comments --
Some of these occur several times -- copy n pasted? Can you search
to find all dups?
+ /* 128-bit multipy by 10 instruction, result is lower 128-bits */
+ Iop_MulI128by10,
Nit: please fix typos (multipy) (in various places)
+++ b/memcheck/mc_transl
[valgrind] [Bug 357338] disInstr(arm64): unhandled instruction 0x5E140020
https://bugs.kde.org/show_bug.cgi?id=357338 Julian Seward changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Julian Seward --- Fixed (all SHA* instructions) in vex r3225, tests in valgrind r15908. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 360378] arm64: Unhandled instruction 0x5E280844 (sha1h s4, s2)
https://bugs.kde.org/show_bug.cgi?id=360378 Julian Seward changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Julian Seward --- Fixed (all SHA* instructions) in vex r3225, test cases in vex r15908. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 359838] arm64: Unhandled instruction 0xD5033F5F (clrex)
https://bugs.kde.org/show_bug.cgi?id=359838 Julian Seward changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Julian Seward --- Fixed, vex r3227. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 359952] Unrecognised PCMPESTRM variants
https://bugs.kde.org/show_bug.cgi?id=359952 Julian Seward changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Julian Seward --- Fixed (both 0x70 and 0x19), vex r3228, tests valgrind r15910. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 351491] Unrecognised instruction in library compiled with -mavx -ffast-math -O3
https://bugs.kde.org/show_bug.cgi?id=351491 Julian Seward changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID CC||jsew...@acm.org --- Comment #1 from Julian Seward --- I am inclined to think that this has been fixed in more recent versions. You filed this against 3.9.0, which is pretty old. Have you tried with 3.11.0? This is an AVX vector compare instruction, one of the vcmp*ss family, but exactly which one I can't tell from your report, because the instruction is unfortunately more than 8 bytes long, and the report only contains the first 8 bytes of the instruction. I checked the trunk sources, which are similar in this regard to 3.11.0, and it looks like all vcmp*ss variants are implemented. So I am going to close this as already-fixed. If you can still repro it in 3.11.0 or the trunk, please feel free to reopen it. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 351726] vex amd64->IR: unhandled instruction bytes: 0xC5 0xF3 0xC2 0x15 0xEB 0x7C 0x2 0x0
https://bugs.kde.org/show_bug.cgi?id=351726 Julian Seward changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #2 from Julian Seward --- I am inclined to think this was fixed in 3.11, but I can't be sure because I don't know exactly what the instruction is. It is more than 8 bytes long but the insn printer has only printed out the first 8 bytes, unfortunately. I can see it's a vmpsd 3-arg insn, somewhat like this vcmpsd $0x90,0x27ceb(%rip),%xmm1,%xmm2 but exactly which variant (0x90 ? something else) I don't know. Am going to close on the basis that it is actually fixed now. If you can still reproduce this with 3.11.0 or the trunk, please feel free to reopen. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 356138] vex amd64->IR unhandled instruction bytes 0x8F 0xEA 0x78 0x10 0xD2 0x6 0x6 0x0
https://bugs.kde.org/show_bug.cgi?id=356138 --- Comment #3 from Julian Seward --- Is possibly bextr $0x1000606,%edx,%edx -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 360415] amd64 instructions ADCX and ADOX are not implemented in VEX
https://bugs.kde.org/show_bug.cgi?id=360415 --- Comment #2 from Julian Seward --- jacobly.alt, what context (library, use case, etc) do these instructions appear in? I am surprised they don't get complained-about more. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 356715] vex amd64->IR: unhandled instruction bytes: 0xC4 0xE2 0x7D 0x13 0x4 0x4A 0xC5 0xFC
https://bugs.kde.org/show_bug.cgi?id=356715 --- Comment #1 from Julian Seward --- c4 e2 7d 13 04 4avcvtph2ps (%rdx,%rcx,2),%ymm0 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 357932] vex amd64->IR: unhandled instruction bytes: 0xF2 0x49 0xF 0x5D and 0xF2 0x49 0xF 0x5F
https://bugs.kde.org/show_bug.cgi?id=357932 --- Comment #1 from Julian Seward --- f2 49 0f 5d 00 rex.WB minsd (%r8),%xmm0 f2 49 0f 5f 00 rex.WB maxsd (%r8),%xmm0 I'm sure these insns are handled really. It's just the redundant rex.WB prefix that is causing them not to get decoded. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 362935] [AsusWRT] Assertion 'sizeof(TTEntryC) <= 88' failed
https://bugs.kde.org/show_bug.cgi?id=362935 --- Comment #4 from Julian Seward --- Err, sorry for the stupid bug. That value needs to be 96 on arm-linux, not 88. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 362935] [AsusWRT] Assertion 'sizeof(TTEntryC) <= 88' failed
https://bugs.kde.org/show_bug.cgi?id=362935 Julian Seward changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #5 from Julian Seward --- Fixed, r15912. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 353727] unhandled instruction bytes: 0x66 0xF 0x3A 0x62 0xD1 0x72 0x45 0x3B __intel_sse4_strspn
https://bugs.kde.org/show_bug.cgi?id=353727 Julian Seward changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #1 from Julian Seward --- Fixed, vex r3230, test cases valgrind r15913. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 353384] unhandled instruction bytes: 0x66 0xF 0x3A 0x62 0xD1 0x62 0x41 0x3B __intel_sse4_strpbrk
https://bugs.kde.org/show_bug.cgi?id=353384 Julian Seward changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #1 from Julian Seward --- Fixed, vex r3230, test cases valgrind r15913. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 366344] Multiple unhandled instruction for Aarch64 (0x0EE0E020, 0x1AC15800, 0x4E284801, 0x5E040023, 0x5E056060)
https://bugs.kde.org/show_bug.cgi?id=366344 --- Comment #2 from Julian Seward --- Try using the trunk. That supports all the crypto instructions in 64-bit mode. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 366344] Multiple unhandled instruction for Aarch64 (0x0EE0E020, 0x1AC15800, 0x4E284801, 0x5E040023, 0x5E056060)
https://bugs.kde.org/show_bug.cgi?id=366344 --- Comment #3 from Julian Seward --- Ah, sorry, I failed to read comment 1. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 366345] Dirty compile from m_libcbase.c and vgdb-invoker-ptrace.c
https://bugs.kde.org/show_bug.cgi?id=366345 --- Comment #2 from Julian Seward --- What version of gcc is this? Do you get these warnings if you don't set CFLAGS yourself? We've played with the flags from time to time over the years, but mostly you can't crank much more performance out of it by fiddling with them, so you'd be well advised just to use the default values. For one thing, performance is largely determined by the quality of the code the JIT creates, so changing the CFLAGS will have no effect there. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 360574] Wrong parameter type for an ashmem ioctl() call on Android and ARM64
https://bugs.kde.org/show_bug.cgi?id=360574 --- Comment #1 from Julian Seward --- Anton: I don't have an easily available arm64-android device to test on. But I think this is an easy fix. If I get you a patch, can you test it for me? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 360571] Error about the Android Runtime reading below the stack pointer on ARM
https://bugs.kde.org/show_bug.cgi?id=360571 --- Comment #1 from Julian Seward --- (In reply to Anton Kirilov from comment #0) > The assembly language code that is emitted by ART at the beginning of each > method, and that causes the warning, looks like this: > > sub r12, sp, #8192 > ldr.w r12, [r12, #0] My understanding is as follows. The loaded value is not actually used. The load is only performed so as to see if it is actually possible, or whether it takes a segfault on a no-access guard page placed at the lowest address in the stack area. Is that correct? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 357673] crash if I try to run valgrind with a binary link with libcurl
https://bugs.kde.org/show_bug.cgi?id=357673 --- Comment #1 from Julian Seward --- This was a bug caused by incorrectly accepting a 32 bit v8 crypto instruction when it was not in fact supported. The invalid-IR failure was fixed in vex r3233. Implementation of 32 bit v8 crypto instructions is currently in progress, with AESD/AESE/AESMC/AESIMC now implemented. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 360574] Wrong parameter type for an ashmem ioctl() call on Android and ARM64
https://bugs.kde.org/show_bug.cgi?id=360574 --- Comment #3 from Julian Seward --- The problem is that the wrappers for android-specific ioctls on 64-bit ARM are not enabled, so it handles them using the generic ioctl logic, which in this case isn't appropriate. Can you try this patch? Index: coregrind/m_syswrap/syswrap-linux.c === --- coregrind/m_syswrap/syswrap-linux.c(revision 15922) +++ coregrind/m_syswrap/syswrap-linux.c(working copy) @@ -7082,7 +7082,8 @@ break; # if defined(VGPV_arm_linux_android) || defined(VGPV_x86_linux_android) \ - || defined(VGPV_mips32_linux_android) + || defined(VGPV_mips32_linux_android) \ + || defined(VGPV_arm64_linux_android) /* ashmem */ case VKI_ASHMEM_GET_SIZE: case VKI_ASHMEM_SET_SIZE: @@ -9574,7 +9575,8 @@ break; # if defined(VGPV_arm_linux_android) || defined(VGPV_x86_linux_android) \ - || defined(VGPV_mips32_linux_android) + || defined(VGPV_mips32_linux_android) \ + || defined(VGPV_arm64_linux_android) /* ashmem */ case VKI_ASHMEM_GET_SIZE: case VKI_ASHMEM_SET_SIZE: Index: include/vki/vki-linux.h === --- include/vki/vki-linux.h(revision 15922) +++ include/vki/vki-linux.h(working copy) @@ -3009,7 +3009,8 @@ //-- #if defined(VGPV_arm_linux_android) || defined(VGPV_x86_linux_android) \ -|| defined(VGPV_mips32_linux_android) +|| defined(VGPV_mips32_linux_android) \ +|| defined(VGPV_arm64_linux_android) #define VKI_ASHMEM_NAME_LEN 256 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 366344] Multiple unhandled instruction for Aarch64 (0x0EE0E020, 0x1AC15800, 0x4E284801, 0x5E040023, 0x5E056060)
https://bugs.kde.org/show_bug.cgi?id=366344 --- Comment #4 from Julian Seward --- (In reply to Jeffrey Walton from comment #1) > It looks like 3.12-SVN is missing the some of the instructions for the CRC32 > checks: > ARM64 front end: data_processing_register > disInstr(arm64): unhandled instruction 0x1AC15800 > disInstr(arm64): 0001'1010 1100'0001 0101'1000 ' Fixed, vex r3237. All 8 of the CRC instructions should work now. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 360574] Wrong parameter type for an ashmem ioctl() call on Android and ARM64
https://bugs.kde.org/show_bug.cgi?id=360574 --- Comment #5 from Julian Seward --- Fixed, valgrind r15923. Thanks for the test. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 360574] Wrong parameter type for an ashmem ioctl() call on Android and ARM64
https://bugs.kde.org/show_bug.cgi?id=360574 Julian Seward changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 366344] Multiple unhandled instruction for Aarch64 (0x0EE0E020, 0x1AC15800, 0x4E284801, 0x5E040023, 0x5E056060)
https://bugs.kde.org/show_bug.cgi?id=366344 Julian Seward changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Julian Seward --- Test cases in r15924, 15925. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 366464] disInstr(arm): unhandled instruction: 0xF1010200
https://bugs.kde.org/show_bug.cgi?id=366464 --- Comment #1 from Julian Seward --- Can you use objdump -d to find out what instruction that actually is? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 360571] Error about the Android Runtime reading below the stack pointer on ARM
https://bugs.kde.org/show_bug.cgi?id=360571 --- Comment #3 from Julian Seward --- (In reply to Anton Kirilov from comment #0) > Currently, the workaround that I have been using is manually patching the > Valgrind source code (in particular, the VG_GCC296_BUG_STACK_SLOP constant > in memcheck/mc_errors.c), but a better solution is to introduce a way to > configure that value at runtime. [..] That would work, but I think we can do something a bit better here. Using a renamed and parameterised version of --workaround-gcc296-bugs will have the effect that all accesses below SP, down to the relevant offset -- in this case, 8192 -- will be ignored, and so any other invalid accesses below SP due to real bugs will get ignored. An alternative is to introduce a new flag, something like this (eg) --ignore-accesses-below-sp-range=- so that just the specified range is ignored. This would work since (AFAICS) your accesses are always at a fixed offset, -8192, from SP. Hence you could use: --ignore-accesses-below-sp-range=8189,8192 Then --workaround-gcc296-bugs=yes can be deprecated and declared to be a synonym for --ignore-accesses-below-sp-range=0,1023 Mark: would that also work for your use case(s)? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 360571] Error about the Android Runtime reading below the stack pointer on ARM
https://bugs.kde.org/show_bug.cgi?id=360571 --- Comment #5 from Julian Seward --- (In reply to Anton Kirilov from comment #4) > Just a quick idea - do you think it is worth it supporting more than one > range (e.g. for running code generated by a compiler that misbehaves in the > same way as GCC 2.96 in an environment similar to Android)? Well, not really. The gcc-2.96 style read/write below SP errors are real bugs and I'd prefer to make it hard to hide those :-). In the worst case you could simply use --ignore-accesses-below-sp-range=0,8191 and then they would all disappear. Do you have an actual use case like this? Or is it more of a theoretical question? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 364948] Add IBM ISA 3.0 support, patch set 5
https://bugs.kde.org/show_bug.cgi?id=364948 --- Comment #9 from Julian Seward --- Thanks for the changes. Both patches look OK to me. Land. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 352364] ppc64: --expensive-definedness-checks=yes is not quite working here
https://bugs.kde.org/show_bug.cgi?id=352364
--- Comment #2 from Julian Seward ---
Some more analysis:
typedef
struct { unsigned char c; int i; void *foo;
} S;
int main (int argc, char **argv) {
S x;
S *s = &x;
s->c = 1;
if (s->c == 0 && s->i == 205 && s->foo == s) return 1;
return 0;
}
/*
13a0 <.main>:
13a0: 39 20 00 01 li r9,1
13a4: 38 60 00 00 li r3,0
13a8: 99 21 ff f0 stb r9,-16(r1)
13ac: 60 42 00 00 ori r2,r2,0
13b0: e9 21 ff f0 ld r9,-16(r1)
13b4: 79 29 46 00 rldicl r9,r9,8,24
13b8: 79 29 c0 02 rotldi r9,r9,56
13bc: 2b a9 00 cd cmpldi cr7,r9,205
13c0: 4c 9e 00 20 bnelr cr7 <---here
13c4: e9 21 ff f8 ld r9,-8(r1)
13c8: 38 61 ff f0 addir3,r1,-16
13cc: 7c 63 4a 78 xor r3,r3,r9
13d0: 7c 63 00 74 cntlzd r3,r3
13d4: 78 63 d1 82 rldicl r3,r3,58,6
13d8: 7c 63 07 b4 extsw r3,r3
13dc: 4e 80 00 20 blr
-- IMark(0x13B0, 4, 0) --
t33 = LDbe:I64(Add64(t29,0xFFF0:I64))
-- IMark(0x13B4, 4, 0) --
t34 = And64(Or64(Shl64(t33,0x8:I8),Shr64(t33,0x38:I8)),0xFF:I64)
-- IMark(0x13B8, 4, 0) --
t48 = Or64(Shl64(t34,0x38:I8),Shr64(t34,0x8:I8))
PUT(88) = t48
-- IMark(0x13BC, 4, 0) --
t54 = 64to8(CmpORD64U(t48,0xCD:I64))
Simplified:
t33 = loaded value
t34 = Rol64(t33, 8) & 0xFF__
t48 = Ror64(t34, 8)
t54 = 64to8(CmpORD64U(t48,0xCD:I64))
*/
The t33 -> t48 transformation, is (MSB on the left):
t33 = A B C D E F G H
Rol(t33, 8) = B C D E F G H A
t34 = Rol(t33, 8) & 0xFF__ = 0 0 0 E F G H A
t48 = Ror(t34, 8) = A 0 0 0 E F G H
So the two rotates in opposite directions serve only to temporarily
put the to-be-zeroed-out area at the top of the word, since rldicl can
only make a bit field immediate that is "anchored" at one end of the
word or the other.
Clearly A is 'c' in the struct and 'E F G H' must be 'i'.
After 13a8, memory at -16(r1) is
-16 -15 -14 -13 -12 -11 -10 -9
1 U U U U U U U
when loaded (bigendian) we get a 64-bit word, with MSB on the left here:
1 U U U U U U U
after masking per the above it is
1 0 0 0 U U U U
and are comparing it with 0 0 0 0 0 0 0 205
This seems to me to be a case that would be correctly handled by
expensiveCmpEQorNE() (mc_translate.c:983, see comment preceding it).
But that applies only to Cmp{EQ,NE}{32,64} and the ppc front end
doesn't produce those. Instead it produces CmpORD{U,S}{32,64}.
In effect the amd64/x86 (and other, to some extent) front ends together
with ir_opt.c succeed in recovering, from the original instruction stream,
the actual condition (==, !=, >, >=, <=, <, signed or unsigned) that gcc/clang
compiled. In this case
13bc: 2b a9 00 cd cmpldi cr7,r9,205
13c0: 4c 9e 00 20 bnelr cr7 <---here
we know that really this is a != comparison, and if the front end could
have recovered that, creating a CmpNE64, then it would have been instrumented
by expensiveCmpEQorNE and we wouldn't have had the false positive.
I guess we could redo doCmpORD so that it performs the "expensive"
interpretation
for EQ# rather than the "standard interp", per the comments in it. But that
would slow down all comparisons, including the 99.99% that don't need this
level of accuracy.
A different approach would be to redo how the ppc condition codes are
translated
into IR, and in particular to attempt to recover the actual compared condition,
like with the amd64/x86/arm/arm64 front ends. And get rid of
CmpORD{32,64}{U,S}.
That would in a way be better, since it would mean that ppc code benefitted
from the same improvements in definedness tracking in comparisons that all the
other architectures do. This isn't straightforward, though -- might be a week
of work.
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 352364] ppc64: --expensive-definedness-checks=yes is not quite working here
https://bugs.kde.org/show_bug.cgi?id=352364
--- Comment #3 from Julian Seward ---
In this example, "cmpld ; bne" translates to essentially this
// the cmpld
t54 = 64to8(CmpORD64U(t48,0xCD:I64))
// the bne
if (CmpEQ32(Xor32(And32(8Uto32(t54),0x2:I32),0x2:I32),0x0:I32))
{ PUT(1296) = 0x13C4:I64; exit-Boring }
CmpORD64U produces a value that is either 8, 4 or 2, with 8 meaning
"<", 4 meaning ">" and 2 meaning "=". The bne translation then
inspects t54 bit 1 (intel encoding) (hence the use of 0x2). This
completely obscures the fact that what we really want is simply
if (CmpNE64(t48,0xCD:I64) { PUT(1296) = 0x13C4:I64; exit-Boring }
The tricky part is to change the generated IR so that it directly
exposes the condition on which the branch is based, yet make it
possible for later instructions to recover a correct value for CR0
.. CR7 should they wish to. Maybe we should change the ppc front end
to use a thunk-based representation as most of the other front ends
do, since that does more or less facilitate all of the above.
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 330617] ppc false positive conditional jump depends on uninitialised value
https://bugs.kde.org/show_bug.cgi?id=330617 --- Comment #8 from Julian Seward --- Properly fixing bug 352364 (https://bugs.kde.org/show_bug.cgi?id=352364) will go a long way to fixing this one too. They are not exact duplicates, though. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 369175] jm_vec_isa_2_07 test crashes on ppc64
https://bugs.kde.org/show_bug.cgi?id=369175 --- Comment #3 from Julian Seward --- This kind of thing could well be due to incorrect register allocation around the calls, perhaps corrupting the values passed to the calls or corrupting values in registers around the call site, that both caller and callee expect the other to preserve. Maybe something along those lines. I tried to reproduce this on gcc112.fsffrance.org (a P8 system) but failed -- it runs OK. I'd be happy to chase this if I could reproduce on a machine that I can access. Failing that .. I'd suggest: (1) make the smallest possible testcase that segfaults (2) make sure it still segfaults with --tool=none (3) with --tool=none, run it with --trace-flags=10001110 and --trace-notbelow= set to the appropriate value so you actually get output for the failing block. From that we might be able to guess what the problem is. (4) Find the failing instruction in GDB by setting env var VALGRIND_LAUNCHER=(to nothing) and then running gdb none/none-ppc64be-linux run --tool=none ./path/to/the/test/binary and disassemble say 10 insns each side of the failing insn, so we can locate it in the JIT generated code. Be aware that GDB may catch segfaults that are unrelated to this crash, prior to the crash point; allow it to pass those on to valgrind to be handled. (5) Post the results from (3) and (4) here. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 369175] jm_vec_isa_2_07 test crashes on ppc64
https://bugs.kde.org/show_bug.cgi?id=369175 --- Comment #4 from Julian Seward --- Comment 3 assumes that the block that segfaults is the same one where the (we assume) mis-translation occurred. It might be that some previous block was mis-translated and causes the simulated machine state to be corrupted, and only in some later block does it crash. But that's a less likely scenario. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 367995] Integration of memcheck with custom memory allocator
https://bugs.kde.org/show_bug.cgi?id=367995 --- Comment #16 from Julian Seward --- Philippe, thank you for looking at this. And Ruurd, for your patience. > The overhead is only incurred by custom allocators using the auto-free > feature, > not by any existing applications or allocators. In that case, then I am happy to go with it. Philippe, what do you think? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 357932] vex amd64->IR: unhandled instruction bytes: 0xF2 0x49 0xF 0x5D and 0xF2 0x49 0xF 0x5F
https://bugs.kde.org/show_bug.cgi?id=357932 --- Comment #5 from Julian Seward --- Mark, I think the patch is OK. In these insns we have, redundantly: REX.W=1, which says that this insn is 64-bits wide w.r.t. how it interacts with the integer register set, which is irrelevant because it doesn't interact with the integer register set at all, apart from the (%r8) address, for which REX.W isn't relevant, and REX.B=1, which supplies the "extra" (4th) register-number bit for some 3rd register field which the insn doesn't have -- there are only 2 registers mentioned. As to where these come from, I have often wondered that. I suspect it is a buggy non-GNU assembler, but really I don't know. The hardware ignores these redundant prefixes but V is stricter. Fortunately GNU as is very good about not generating them. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 369175] jm_vec_isa_2_07 test crashes on ppc64
https://bugs.kde.org/show_bug.cgi?id=369175
--- Comment #5 from Julian Seward ---
Still can't repro it, but with a test case for this insn, the two calls look
like
this:
IR and virtual-registerised code:
-- t127 =
1Sto32(32to1(64to32(And64(is_BCDstring128_helper{0x38174610}(0x1:I64,t117,t118):I64,is_BCDstring128_helper{0x38174610}(0x1:I64,t120,t121):I64
li_word %vR721,0x0001
mr %r3,%vR721
mr %r4,%vR117
mr %r5,%vR118
call: { li_word %r10,0x38174610 ; mtctr r10 ; bctrl
[r3,r4,r5,RLPri_Int] }
mr %vR722,%r3
li_word %vR723,0x0001
mr %r3,%vR723
mr %r4,%vR120
mr %r5,%vR121
call: { li_word %r10,0x38174610 ; mtctr r10 ; bctrl
[r3,r4,r5,RLPri_Int] }
mr %vR724,%r3
and %vR720,%vR722,%vR724
andi. %vR725,%vR720,1
cmplwi %cr7,%vR725,1
set (cr7.eq=1),%vR719: { mfcr r0 ; rlwinm %vR719,r0,31,31,31 }
slwi %vR719,%vR719,31
srawi %vR719,%vR719,31
mr %vR127,%vR719
Register allocation around the two calls:
194 li_word %r14,0x0001
195 mr %r3,%r14
196 mr %r4,%r15
197 mr %r5,%r16
198 call: { li_word %r10,0x38174610 ; mtctr r10 ; bctrl
[r3,r4,r5,RLPri_Int] }
199 mr %r14,%r3
200 li_word %r19,0x0001
201 mr %r3,%r19
202 mr %r4,%r17
203 mr %r5,%r18
204 call: { li_word %r10,0x38174610 ; mtctr r10 ; bctrl
[r3,r4,r5,RLPri_Int] }
205 mr %r19,%r3
206 and %r20,%r14,%r19
207 andi. %r14,%r20,1
So the result of the first call is parked in r14, and then we make the second
call. That
seems OK because r14 (in fact, r14 to r28) are callee saved so the result of
the first
call won't get trashed. Also, the args for the second call enter this fragment
in
r19/r18/r17, so we can be fairly sure the first call doesn't trash them. So
there's
nothing *obviously* wrong here that I can see. We need the real crash block.
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 369175] jm_vec_isa_2_07 test crashes on ppc64
https://bugs.kde.org/show_bug.cgi?id=369175
--- Comment #22 from Julian Seward ---
Looking for helper calls in the the whole of guest_ppc_toIR.c, by searching for
the
string "mkIRExprVec_", I found the following non-wrapped uses of function
pointers. They should all be wrapped in fnptr_to_fnentry(). The reason
for my claim of "impossible" in comment 21 is that I would have thought that
the BCD test cases exercise all of these helper functions, so any missing
wrapper would cause the case to segfault. So maybe we don't really yet
understand what is going on.
static IRExpr * is_BCDstring128 (UInt Signed, IRExpr *src)
&is_BCDstring128_helper,
static IRTemp increment_BCDstring (IRExpr *src, IRExpr *carry_in)
&increment_BCDstring32_helper,
&increment_BCDstring32_helper,
&increment_BCDstring32_helper,
&increment_BCDstring32_helper,
static IRExpr * convert_to_zoned ( IRExpr *src, IRExpr *upper_byte )
&convert_to_zoned_helper,
&convert_to_zoned_helper,
static IRExpr * convert_to_national ( IRExpr *src ) {
&convert_to_national_helper,
&convert_to_national_helper,
static IRExpr * convert_from_zoned ( IRExpr *src ) {
&convert_from_zoned_helper,
static IRExpr * convert_from_national ( IRExpr *src ) {
&convert_from_national_helper,
static Bool dis_av_load ( const VexAbiInfo* vbi, UInt theInstr )
&ppc64g_dirtyhelper_LVS,
(although this one doesn't matter, because it is LE only. Still, inconsistent)
same for lvsr a few lines later
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 369175] jm_vec_isa_2_07 test crashes on ppc64
https://bugs.kde.org/show_bug.cgi?id=369175 --- Comment #24 from Julian Seward --- (In reply to Ulrich Weigand from comment #23) > However, adding calls to fnptr_to_fnentry at a high level likewise seems > wrong, since once you've done that, you've forgotten where the function > descriptor was and have no chance of then retrieving the correct TOC value > to load into r2 before the call. And in fact, the crash in comment #7 seems > a typical example of what happens when calling a function without setting up > its TOC pointer correctly. Ulrich, you're right. Valgrind actually kludges this on ppc64be, by completely ignoring the TOC pointer question and not saving or restoring r2 across calls. I suspect that the reason this works is that Valgrind itself is compiled into a statically linked executable, and so there is only ever one required r2 value, which is set up at start time and stays the same for ever more. Does that sound plausible? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 369459] valgrind on arm64 violates the ARMv8 spec (ldxr/stxr)
https://bugs.kde.org/show_bug.cgi?id=369459 --- Comment #3 from Julian Seward --- Andrew, do you know which implementation this is? eg is it a Cortex A-something, or something else? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 371065] www: add CfP for FOSDEM 2017 in valgrind.org NEWS section
https://bugs.kde.org/show_bug.cgi?id=371065 Julian Seward changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Julian Seward --- Committed, www r513. Thanks! -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 369459] valgrind on arm64 violates the ARMv8 spec (ldxr/stxr)
https://bugs.kde.org/show_bug.cgi?id=369459 --- Comment #6 from Julian Seward --- (In reply to Andrew Pinski from comment #5) > One idea I have is to pattern match on the ldxr/stxr sequence and produce a > single instruction in the IR and then decode them after the fact. On consideration, I think this is the least-worst option, but I would propose to do it probably differently to how you envisage. I would leave the front end alone (guest_arm64_toIR.c) and instead do pattern matching on the IR after initial optimisation and before instrumentation. That keeps the IR target independent, and it has the benefit of solving the problem for all targets, not just ARM64. The result of the pattern matching would be a encoded into a new IRStmt kind which encapsulates a complete LL-SC pair. This does have the restriction that the LL and SC would have to be within the same (extended) basic block, since otherwise they won't be in the same IRSB, but I don't think that's much of a restriction. We would then have to mess with all tools and pipeline compilation stages to handle this new construction, but there's no way around that; and we'd need to take care, in register allocation, that there will be no spilling in between the emitted LL and SC, since that would potentially scupper the entire enterprise. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 369459] valgrind on arm64 violates the ARMv8 spec (ldxr/stxr)
https://bugs.kde.org/show_bug.cgi?id=369459 --- Comment #7 from Julian Seward --- Hmm, I see stuff like this: 9858: 885ffe62ldaxr w2, [x19] 985c: 6b1f005fcmp w2, wzr 9860: 54fff7e1b.ne975c <__pthread_mutex_lock+0x44> 9864: 88017e60stxrw1, w0, [x19] so they are not in the same block. Hmm. Back to the drawing board. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 369459] valgrind on arm64 violates the ARMv8 spec (ldxr/stxr)
https://bugs.kde.org/show_bug.cgi?id=369459 --- Comment #9 from Julian Seward --- Maybe we could use Maran's proposal for fixing the same problem on MIPS OCTEON3. https://bugs.kde.org/show_bug.cgi?id=344524#c8 (and 9 and 10). This provides a correct implementation, including coverage of ABA cases, for threads within an application, and (IIUC) CAS-level atomicity between a Valgrinded process and a non-Valgrinded process that communicate via shared memory. So it's not perfect, but it might be good enough. Also, it's simple and non-intrusive and so could be done quickly. I would be inclined to preserve the current implementation and use the above only for cores where the current implementation fails, since the current implementation is ABA-correct both for threads within a process and across processes. IOW the proposal is a best-effort fallback. Andrew, is there a way to automatically detect the relevant cores at startup time, so that V can transparently switch to using the fallback implementation without intervention from the user? Peter, do you have any further information about the assertion that "realworld code doesn't really care"? I'd be interested to know more about that. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 344524] store conditional of guest applications always fail - observed on Octeon3(MIPS)
https://bugs.kde.org/show_bug.cgi?id=344524 --- Comment #12 from Julian Seward --- Maran, the same problem has been reported for ARM64/OCTEON3 at https://bugs.kde.org/show_bug.cgi?id=369459. So let me ask: how well does your proposed solution in comments 9 and 10 work? Did you deploy it? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 371491] handleAddrOverrides() is truncating the segment base address when ASO prefix is used
https://bugs.kde.org/show_bug.cgi?id=371491 --- Comment #2 from Julian Seward --- Sounds plausible, and it's nice that it's easy to fix. But I'm a bit concerned about the untestability of this. Is there no easy way to test this? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 369459] valgrind on arm64 violates the ARMv8 spec (ldxr/stxr)
https://bugs.kde.org/show_bug.cgi?id=369459 --- Comment #11 from Julian Seward --- (In reply to Andrew Pinski from comment #10) Another possibility is to run a test sequence on the host CPU at startup, whilst we are still single threaded, containing LL, SC and some stores in between, and see if it fails. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 369459] valgrind on arm64 violates the ARMv8 spec (ldxr/stxr)
https://bugs.kde.org/show_bug.cgi?id=369459 --- Comment #12 from Julian Seward --- Andrew, do you know how well Maran's proposal https://bugs.kde.org/show_bug.cgi?id=344524#c8 worked on MIPS64r3 (Octeon 3) ? IOW is it worth taking and generalising? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 369459] valgrind on arm64 violates the ARMv8 spec (ldxr/stxr)
https://bugs.kde.org/show_bug.cgi?id=369459 --- Comment #15 from Julian Seward --- (In reply to Peter Maydell from comment #14) > [..] so you might find your > autodetect test code passed but later generated code didn't. True. > Plus on big.LITTLE you might later be running on a CPU with a > different microarchitecture from the one you ran your autodetection > on... Hmm, yes, good point. I hadn't thought of that. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 339596] AMD64 fma4 and xop instructions unsupported. vex amd64->IR: unhandled instruction bytes: 0x8F 0xE8 0x78 0xCD 0xC1 0x4 0xC5 0xF9
https://bugs.kde.org/show_bug.cgi?id=339596 --- Comment #20 from Julian Seward --- (In reply to Mark Wielaard from comment #18) > Here are some testcases for the FMA4 instructions. Excellent. > I haven't looked yet at the XOP instructions. > Maybe it is an idea to do FMA4 and XOP as separate patches? Hmm, no particular opinion on that from here. If you find it more convenient, then yes. > First the 256bit ymm operations aren't supported, so they have been disabled > in the testcase for now. But I am not sure we really should enable the fma4 > cpuid bit in valgrind before we really support them. I agree. Enabling cpuid bits before the all the associated instructions have been implemented has caused us trouble before. > Secondly some 128bit xmm operations should clear the upper 128 bits > of the corresponding YMM register to zeros and don't do so at the moment. In guest_amd64_toIR.c there's a function putYMMRegLoAndZU (ZU = "Zero Upper") which does exactly that. Maybe that would be helpful here? > Lastly the "full 0xFF" testcases do show some differences (but the zeros, > ones and random cases all look fine). It may be that such values are infinities, NaNs etc and we don't handle those quite right. It would be much preferable if we did. I think we should indeed try to achieve bit-identical results to the hardware, and review the cases where that seems to be problematic. At least for initial verification, you could copy the scheme used in randV128() in none/tests/arm64/fp_and_simd.c. This guarantees that all F32 and F64 values embedded within vectors are normalised numbers, and so you can at least differentiate easily, failures caused by incorrect handling of denorms (NaNs, Infs etc) vs failures for other reasons. In the long run though I would prefer bit-identical results. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 352767] Wine/valgrind: Warning: noted but unhandled ioctl 0x5307 with no size/direction hints. (CDROMSTOP)
https://bugs.kde.org/show_bug.cgi?id=352767 --- Comment #1 from Julian Seward --- Austin, do you have a patch for this? Or for bug 348616 ? -- You are receiving this mail because: You are watching all bug changes.
