[valgrind] [Bug 381553] VEX register allocator v3
https://bugs.kde.org/show_bug.cgi?id=381553 Ivo Raisr <iv...@ivosh.net> changed: What|Removed |Added Attachment #106323|0 |1 is obsolete|| --- Comment #11 from Ivo Raisr <iv...@ivosh.net> --- Created attachment 106377 --> https://bugs.kde.org/attachment.cgi?id=106377=edit patch 005 - Valgrind part -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 381713] New: optimize CmpNEx(a, 0) as CmpNEZx(a) in VEX IR
https://bugs.kde.org/show_bug.cgi?id=381713 Bug ID: 381713 Summary: optimize CmpNEx(a, 0) as CmpNEZx(a) in VEX IR Product: valgrind Version: 3.14 SVN Platform: Compiled Sources OS: Linux Status: UNCONFIRMED Severity: minor Priority: NOR Component: vex Assignee: jsew...@acm.org Reporter: iv...@ivosh.net Target Milestone: --- VEX IR optimizer should optimize CmpNEx(a, 0) as CmpNEZx(a). CmpNEx(a, 0) is typically produced by VEX frontends for emulation warnings. For example in guest_x86_toIR.c: 4110 /* Finally, if an emulation warning was reported, 4111side-exit to the next insn, reporting the warning, 4112so that Valgrind's dispatcher sees the warning. */ 4113 stmt( 4114IRStmt_Exit( 4115 binop(Iop_CmpNE32, mkexpr(ew), mkU32(0)), 4116 Ijk_EmWarn, 4117 IRConst_U32( ((Addr32)guest_EIP_bbstart)+delta), 4118 OFFB_EIP 4119) 4120 ); -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 381713] optimize CmpNEx(a, 0) as CmpNEZx(a) in VEX IR
https://bugs.kde.org/show_bug.cgi?id=381713 Ivo Raisr <iv...@ivosh.net> changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Assignee|jsew...@acm.org |iv...@ivosh.net -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 381553] VEX register allocator v3
https://bugs.kde.org/show_bug.cgi?id=381553 --- Comment #10 from Ivo Raisr <iv...@ivosh.net> --- The attached patches for register allocator v3 are able to drive simple programs (such as /bin/true and /bin/date) successfully through. There is still some functionality to be implemented, though. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 381553] VEX register allocator v3
https://bugs.kde.org/show_bug.cgi?id=381553 Ivo Raisr <iv...@ivosh.net> changed: What|Removed |Added Attachment #106260|0 |1 is obsolete|| --- Comment #9 from Ivo Raisr <iv...@ivosh.net> --- Created attachment 106324 --> https://bugs.kde.org/attachment.cgi?id=106324=edit patch 004 - VEX part -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 381553] VEX register allocator v3
https://bugs.kde.org/show_bug.cgi?id=381553 Ivo Raisr <iv...@ivosh.net> changed: What|Removed |Added Attachment #106259|0 |1 is obsolete|| --- Comment #8 from Ivo Raisr <iv...@ivosh.net> --- Created attachment 106323 --> https://bugs.kde.org/attachment.cgi?id=106323=edit patch 004 - Valgrind part -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 381553] VEX register allocator v3
https://bugs.kde.org/show_bug.cgi?id=381553 --- Comment #6 from Ivo Raisr <iv...@ivosh.net> --- It turns out the current version has a design flaw because it does not track rreg live ranges. This manifests for example in this vcode: 82 movq $0x14,%rdi 83 movq %vR12,%rsi 84 movq $0x0,%rdx 85 movq 0xA8(%rbp),%rcx 86 call[4,RLPri_Int] 0x58147900 87 movq %rax,%vR191 88 movq %vR189,%rdi 89 movq %vR28,%rsi 90 movq %vR190,%rdx 91 movq %vR191,%rcx 92 call[4,RLPri_Int] 0x58147900 Imagine that register allocator processes instruction #89 and that %vReg28 is currently spilled. So it will: 1. allocate a "free" register - %rdi 2. generate reload into %rdi: movq (spill_slot), %rdi 3. register allocate "movq %vR28,%rsi" -> "movq %rdi,%rsi" I think it is needed to track rreg live ranges. I will try something simpler than does reg_alloc v2; rreg live ranges will be tracked individually per rreg. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 381553] VEX register allocator v3
https://bugs.kde.org/show_bug.cgi?id=381553 Ivo Raisr <iv...@ivosh.net> changed: What|Removed |Added Attachment #106255|0 |1 is obsolete|| --- Comment #5 from Ivo Raisr <iv...@ivosh.net> --- Created attachment 106260 --> https://bugs.kde.org/attachment.cgi?id=106260=edit patch 003 - VEX part -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 381553] VEX register allocator v3
https://bugs.kde.org/show_bug.cgi?id=381553 Ivo Raisr <iv...@ivosh.net> changed: What|Removed |Added Attachment #106254|0 |1 is obsolete|| --- Comment #4 from Ivo Raisr <iv...@ivosh.net> --- Created attachment 106259 --> https://bugs.kde.org/attachment.cgi?id=106259=edit patch 003 - Valgrind part -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 381553] VEX register allocator v3
https://bugs.kde.org/show_bug.cgi?id=381553 --- Comment #3 from Ivo Raisr <iv...@ivosh.net> --- New VEX register allocator is activated with command line option --vex-regalloc-version=3, for example: $ ./vg-in-place --tool=none --vex-regalloc-version=3 --trace-flags=0110 \ --trace-notbelow=0 /bin/true -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 381553] VEX register allocator v3
https://bugs.kde.org/show_bug.cgi?id=381553 --- Comment #2 from Ivo Raisr <iv...@ivosh.net> --- Created attachment 106255 --> https://bugs.kde.org/attachment.cgi?id=106255=edit patch 002 - VEX part -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 381553] VEX register allocator v3
https://bugs.kde.org/show_bug.cgi?id=381553 --- Comment #1 from Ivo Raisr <iv...@ivosh.net> --- Created attachment 106254 --> https://bugs.kde.org/attachment.cgi?id=106254=edit patch 002 - Valgrind part -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 381553] New: VEX register allocator v3
https://bugs.kde.org/show_bug.cgi?id=381553 Bug ID: 381553 Summary: VEX register allocator v3 Product: valgrind Version: 3.13 SVN Platform: Compiled Sources OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: vex Assignee: jsew...@acm.org Reporter: iv...@ivosh.net Target Milestone: --- Julian Seward designed new VEX register allocator last year. And here is its initial implementation. On amd64/Linux, it manages to allocate 385 superblocks while running "/bin/true" until it bombs out for some reason. There are still a few missing features to implement. However it is believed that compared to the previous register allocator v2 it is: - simpler - faster - perhaps producing slightly worse spilling decisions -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 381553] VEX register allocator v3
https://bugs.kde.org/show_bug.cgi?id=381553 Ivo Raisr <iv...@ivosh.net> changed: What|Removed |Added Assignee|jsew...@acm.org |iv...@ivosh.net Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 CC||iv...@ivosh.net -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 381299] false uninit on new page via sbrk(n)
https://bugs.kde.org/show_bug.cgi?id=381299 Ivo Raisr <iv...@ivosh.net> changed: What|Removed |Added CC||iv...@ivosh.net --- Comment #1 from Ivo Raisr <iv...@ivosh.net> --- Agreed. However great care needs to be taken to distinguish between *first* such allocated space or a *subsequent* one. brk/sbrk were part of POSIX 1997 (and removed in POSIX 2001). The standard said by that time [1]: "The newly-allocated space is set to 0. However, if the application first decrements and then increments the break value, the contents of the reallocated space are unspecified." Linux man pages do not say anything about initial contents. Solaris man page brk(2) says: "Newly allocated space is set to zero. If, however, the same memory space is reallocated to the same process its contents are undefined." [1] http://pubs.opengroup.org/onlinepubs/7908799/xsh/brk.html -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 381162] possible array overrun in VEX register allocator
https://bugs.kde.org/show_bug.cgi?id=381162 --- Comment #11 from Ivo Raisr <iv...@ivosh.net> --- Indeed: ... 5904a71c b p_CmpNEZ32_Or32.5344 5904a720 b p_CmpNEZ32_And32.5340 5904a724 b p_zwiden_load64.5765 5904a728 b p_CmpwNEZ64_Or64.5612 5904a72c B vex_control<=== 5904a748 B vex_traceflags 5904a74c B vex_debuglevel 5904a750 B vex_log_bytes 5904a754 B vex_failure_exit 5904a758 B vex_initdone ... -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 381162] possible array overrun in VEX register allocator
https://bugs.kde.org/show_bug.cgi?id=381162 --- Comment #9 from Ivo Raisr <iv...@ivosh.net> --- Hmm, does not strike me as something obvious... ... 580e1a50 t varstack_show 58003b80 R version 58108f90 T vex_assert_fail 58108f20 T vex_bzero 5904a72c B vex_control <== 5904a74c B vex_debuglevel 5904a754 B vex_failure_exit 58179740 b vex_init_done.25661 5904a758 B vex_initdone 58113d00 T vex_inject_ir ... -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 381162] possible array overrun in VEX register allocator
https://bugs.kde.org/show_bug.cgi?id=381162 --- Comment #7 from Ivo Raisr <iv...@ivosh.net> --- I concur. I hope this will shed some light for a mysterious bug I see on x86/Solaris (not amd64/Solaris) which manifests in the following debug output printed for almost all gdbserver_tests: vex iropt: 4 x unrolling (25 sts -> 100 sts) vex iropt: 2 x unrolling (50 sts -> 100 sts) vex iropt: 2 x unrolling (34 sts -> 68 sts) vex iropt: fold_Expr: no ident rule for: 32HLto64(t47,t47) vex iropt: 8 x unrolling (13 sts -> 104 sts) vex iropt: 2 x unrolling (56 sts -> 112 sts) vex iropt: 8 x unrolling (14 sts -> 112 sts) vex iropt: 2 x unrolling (57 sts -> 114 sts) vex iropt: 2 x unrolling (47 sts -> 94 sts) vex iropt: 2 x unrolling (33 sts -> 66 sts) vex iropt: fold_Expr: no ident rule for: 32HLto64(t68,t68) vex iropt: fold_Expr: no ident rule for: 32HLto64(t62,t62) vex iropt: fold_Expr: no ident rule for: 32HLto64(t66,t66) vex iropt: fold_Expr: no ident rule for: 32HLto64(t57,t57) vex iropt: 2 x unrolling (39 sts -> 78 sts) vex iropt: 2 x unrolling (33 sts -> 66 sts) vex iropt: 2 x unrolling (57 sts -> 114 sts) vex iropt: 2 x unrolling (39 sts -> 78 sts) vex iropt: IRStmt_Exit became unconditional vex iropt: IRStmt_Exit became unconditional vex iropt: 2 x unrolling (32 sts -> 64 sts) vex iropt: 2 x unrolling (44 sts -> 88 sts) vex iropt: IRStmt_Exit became unconditional vex iropt: fold_Expr: no ident rule for: 32HLto64(t118,t118) vex iropt: 2 x unrolling (33 sts -> 66 sts) This is printed only for a brief duration and I can reproduce it outside the 'regtest' harness. For example with nlvgdbsigqueue, following GDB commands in nlvgdbsigqueue.stdinB.gdb, it is printed only after I hit "continue": ../vg-in-place --tool=none --vgdb=yes --vgdb-error=0 --vgdb-prefix=./vgdb-prefix-nlvgdbsigqueue ./sleepers 10 10 1 BSBSBSBS 1 ==9979== Nulgrind, the minimal Valgrind tool ==9979== Copyright (C) 2002-2017, and GNU GPL'd, by Nicholas Nethercote. ==9979== Using Valgrind-3.14.0.SVN and LibVEX; rerun with -h for copyright info ==9979== Command: ./sleepers 10 10 1 BSBSBSBS 1 ==9979== ==9979== (action at startup) vgdb me ... ==9979== ==9979== TO DEBUG THIS PROCESS USING GDB: start GDB like this ==9979== /path/to/gdb ./sleepers ==9979== and then give GDB the following command ==9979== target remote | /export/home/tester1/valgrind-32/gdbserver_tests/../.in_place/../../bin/vgdb --vgdb-prefix=./vgdb-prefix-nlvgdbsigqueue --pid=9979 ==9979== --pid is optional if only one valgrind process is running ==9979== [here all the signals are queued as described in nlvgdbsigqueue.stdinB.gdb] [then do "continue" in GDB] vex iropt: 4 x unrolling (20 sts -> 80 sts) vex iropt: 2 x unrolling (41 sts -> 82 sts) vex iropt: 4 x unrolling (29 sts -> 116 sts) vex iropt: 2 x unrolling (38 sts -> 76 sts) vex iropt: 8 x unrolling (12 sts -> 96 sts) vex iropt: 2 x unrolling (32 sts -> 64 sts) vex iropt: 8 x unrolling (13 sts -> 104 sts) vex iropt: 4 x unrolling (30 sts -> 120 sts) vex iropt: 2 x unrolling (39 sts -> 78 sts) vex iropt: 4 x unrolling (16 sts -> 64 sts) vex iropt: 8 x unrolling (15 sts -> 120 sts) vex iropt: 2 x unrolling (34 sts -> 68 sts) vex iropt: not unrolling (75 sts) vex iropt: 4 x unrolling (29 sts -> 116 sts) vex iropt: 4 x unrolling (16 sts -> 64 sts) vex iropt: 8 x unrolling (15 sts -> 120 sts) vex iropt: 4 x unrolling (23 sts -> 92 sts) vex iropt: IRStmt_Exit became unconditional vex iropt: 8 x unrolling (13 sts -> 104 sts) vex iropt: 8 x unrolling (12 sts -> 96 sts) vex iropt: IRStmt_Exit became unconditional vex iropt: 2 x unrolling (35 sts -> 70 sts) loops/sleep_ms/burn/threads_spec/affinity: 10 10 1 BSBSBSBS 1 vex iropt: IRStmt_Exit became unconditional vex iropt: 2 x unrolling (50 sts -> 100 sts) vex iropt: IRStmt_Exit became unconditional vex iropt: 2 x unrolling (31 sts -> 62 sts) vex iropt: 2 x unrolling (34 sts -> 68 sts) vex iropt: 8 x unrolling (13 sts -> 104 sts) vex iropt: 2 x unrolling (50 sts -> 100 sts) Brussels ready to sleep and/or burn London ready to sleep and/or burn Petaouchnok ready to sleep and/or burn main ready to sleep and/or burn Unfortunately I cannot attach to the main Valgrind process with gdb to watch who has supposedly mistakenly overwritten vex_control.iropt_verbosity. Because by that time procfs agent thread is created in the process and gdb is confused about it and crashes. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 381162] possible array overrun in VEX register allocator
https://bugs.kde.org/show_bug.cgi?id=381162 Ivo Raisr <iv...@ivosh.net> changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Ivo Raisr <iv...@ivosh.net> --- Fixed in Valgrind SVN commit r16445 (NEWS) and VEX SVN commit r3392. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 381162] possible array overrun in VEX register allocator
https://bugs.kde.org/show_bug.cgi?id=381162 Ivo Raisr <iv...@ivosh.net> changed: What|Removed |Added Summary|array overrun in VEX|possible array overrun in |register allocator |VEX register allocator -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 381162] array overrun in VEX register allocator
https://bugs.kde.org/show_bug.cgi?id=381162 --- Comment #1 from Ivo Raisr <iv...@ivosh.net> --- Created attachment 106081 --> https://bugs.kde.org/attachment.cgi?id=106081=edit proposed patch -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 381162] array overrun in VEX register allocator
https://bugs.kde.org/show_bug.cgi?id=381162 Ivo Raisr <iv...@ivosh.net> changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 381162] array overrun in VEX register allocator
https://bugs.kde.org/show_bug.cgi?id=381162 Ivo Raisr <iv...@ivosh.net> changed: What|Removed |Added Assignee|jsew...@acm.org |iv...@ivosh.net CC||iv...@ivosh.net -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 381162] New: array overrun in VEX register allocator
https://bugs.kde.org/show_bug.cgi?id=381162 Bug ID: 381162 Summary: array overrun in VEX register allocator Product: valgrind Version: 3.13 SVN Platform: Compiled Sources OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: vex Assignee: jsew...@acm.org Reporter: iv...@ivosh.net Target Milestone: --- In function doRegisterAllocation(), array "reg_usage_arr" is currently allocated with: LibVEX_Alloc_inline(sizeof(HRegUsage) * instrs_in->arr_used - 1). However I think this is wrong. It should be allocated with: LibVEX_Alloc_inline(sizeof(HRegUsage) * instrs_in->arr_used); That's because rreg_usage_arr is indexed with [0 .. arr_used-1] so its length needs to be at least arr_used (and not arr_used-1). -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 380397] s390x: __GI_strcspn() replacemenet needed
https://bugs.kde.org/show_bug.cgi?id=380397 Ivo Raisr <iv...@ivosh.net> changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Ivo Raisr <iv...@ivosh.net> --- Fixed in Valgrind SVN r16436. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 380397] s390x: __GI_strcspn() replacemenet needed
https://bugs.kde.org/show_bug.cgi?id=380397 --- Comment #4 from Ivo Raisr <iv...@ivosh.net> --- I will integrate the change with __GI_strcspn() after Valgrind 3.13 is released. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 380397] s390x: __GI_strcspn() replacemenet needed
https://bugs.kde.org/show_bug.cgi?id=380397 Ivo Raisr <iv...@ivosh.net> changed: What|Removed |Added Summary|s390x: False-positive |s390x: __GI_strcspn() |"invalid read" for strtok() |replacemenet needed -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 380397] s390x: False-positive "invalid read" for strtok()
https://bugs.kde.org/show_bug.cgi?id=380397 Ivo Raisr <iv...@ivosh.net> changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Assignee|jsew...@acm.org |iv...@ivosh.net -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 380397] s390x: False-positive "invalid read" for strtok()
https://bugs.kde.org/show_bug.cgi?id=380397 --- Comment #2 from Ivo Raisr <iv...@ivosh.net> --- Created attachment 105808 --> https://bugs.kde.org/attachment.cgi?id=105808=edit simple patch -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 380397] s390x: False-positive "invalid read" for strtok()
https://bugs.kde.org/show_bug.cgi?id=380397 Ivo Raisr <iv...@ivosh.net> changed: What|Removed |Added CC||iv...@ivosh.net --- Comment #1 from Ivo Raisr <iv...@ivosh.net> --- Seems like a simple wrapper for "__strcspn_c" would suffice in shared/vg_replace_strmem.c. Would you please try the following patch (also attached) against Valgrind from SVN [1] --- shared/vg_replace_strmem.c (revision 16420) +++ shared/vg_replace_strmem.c (working copy) @@ -1721,6 +1721,7 @@ #if defined(VGO_linux) STRCSPN(VG_Z_LIBC_SONAME, strcspn) + STRCSPN(VG_Z_LIBC_SONAME, __strcspn_c) #elif defined(VGO_darwin) [1] http://valgrind.org/downloads/repository.html -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 379525] Support more x86 nop opcodes
https://bugs.kde.org/show_bug.cgi?id=379525 Ivo Raisr <iv...@ivosh.net> changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #36 from Ivo Raisr <iv...@ivosh.net> --- 32-bit tests connected under SVN r16423. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 379525] Support more x86 nop opcodes
https://bugs.kde.org/show_bug.cgi?id=379525 --- Comment #35 from Ivo Raisr <iv...@ivosh.net> --- For Solaris and OS X, tests connected under SVN r16422. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 379525] Support more x86 nop opcodes
https://bugs.kde.org/show_bug.cgi?id=379525 --- Comment #34 from Ivo Raisr <iv...@ivosh.net> --- Follow up SVN commit r16421 which splits the tests into three. Another commit will follow, enabling cet_nops_fs on Solaris and cet_nops_gs on OS X. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 379525] Support more x86 nop opcodes
https://bugs.kde.org/show_bug.cgi?id=379525 --- Comment #19 from Ivo Raisr <iv...@ivosh.net> --- (In reply to Tanya from comment #17) > (In reply to Julian Seward from comment #9) > > Committed, r3383, r16415. Thanks for the patches. > > Julian, > Would it be possible to patch the 32-bit instruction parser as well? Sure, no problem. Please provide a patch and test cases. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 379525] Support more x86 nop opcodes
https://bugs.kde.org/show_bug.cgi?id=379525
--- Comment #18 from Ivo Raisr <iv...@ivosh.net> ---
(In reply to H.J. Lu from comment #16)
> (In reply to Ivo Raisr from comment #14)
> > And this is a minimalistic reproducer with the latest Valgrind sources:
> >
> > --
> > #include
> >
> > int main ()
> > {
> > __asm__ __volatile__ (".byte 0x65, 0x0f, 0x19, 0xff" :::"cc","memory");
> > return 0;
> > }
>
> Does it run on your machine outside of valgrind?
Yes, it does.
The root cause is described in comment #15.
I cannot fix this myself because cet_nops.c uses byte sequences and does not
use assembler mnemonics. My toolchain is not able to properly decode all byte
sequences, even though I (and my CPU) believe they are valid ones.
It would help immensely if you could divide the file (or better split it) in
three sections:
- with gs prefix
- with fs prefix
- with no prefix
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 379525] Support more x86 nop opcodes
https://bugs.kde.org/show_bug.cgi?id=379525 --- Comment #15 from Ivo Raisr <iv...@ivosh.net> --- So the real "culprit" is that on: amd64/Linux: guest_amd64_assume_fs_is_const = True guest_amd64_assume_gs_is_const = True amd64/Darwin: guest_amd64_assume_fs_is_const = False guest_amd64_assume_gs_is_const = True amd64/Solaris: guest_amd64_assume_fs_is_const = True guest_amd64_assume_gs_is_const = True And amd64 decoder in disInstr_AMD64_WRK(), around lines 32238-32243 fails with: /* We have a %fs prefix. Reject it if there's no evidence in 'vbi' that we should accept it. */ if ((pfx & PFX_FS) && !vbi->guest_amd64_assume_fs_is_const) goto decode_failure; /* Ditto for %gs prefixes. */ if ((pfx & PFX_GS) && !vbi->guest_amd64_assume_gs_is_const) goto decode_failure; --- This means that the test cases in cet_nops are probably not valid for all OSes. Only Linux can have both "fs" and "gs" prefixes, OS X only "gs" and Solaris only "fs". I think this could be easily fixed by simple #ifdefery in cet_ops.c. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 379525] Support more x86 nop opcodes
https://bugs.kde.org/show_bug.cgi?id=379525
--- Comment #14 from Ivo Raisr <iv...@ivosh.net> ---
And this is a minimalistic reproducer with the latest Valgrind sources:
--
#include
int main ()
{
__asm__ __volatile__ (".byte 0x65, 0x0f, 0x19, 0xff" :::"cc","memory");
return 0;
}
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 379525] Support more x86 nop opcodes
https://bugs.kde.org/show_bug.cgi?id=379525
--- Comment #13 from Ivo Raisr <iv...@ivosh.net> ---
I've updated GIT repo at sourceware.org.
So the test program under Valgrind crashes at cet_nop.c:42 which is this line:
42 __asm__ __volatile__ (".byte 0xf3, 0x66, 0x64, 0x0f, 0x19, 0xff"
:::"cc","memory");
GDB disassembles it as "gs nop %edi". It is actually the first "nop" with 'gs'
prefix. Perhaps this is the smoking gun?
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 379525] Support more x86 nop opcodes
https://bugs.kde.org/show_bug.cgi?id=379525 --- Comment #10 from Ivo Raisr <iv...@ivosh.net> --- I get the following error output from Valgrind run: $ ./vg-in-place --tool=none none/tests/amd64/cet_nops ==13161== Nulgrind, the minimal Valgrind tool ==13161== Copyright (C) 2002-2017, and GNU GPL'd, by Nicholas Nethercote. ==13161== Using Valgrind-3.13.0.SVN and LibVEX; rerun with -h for copyright info ==13161== Command: none/tests/amd64/cet_nops ==13161== start doing absolutely nothing .. vex amd64->IR: unhandled instruction bytes: 0x65 0xF 0x19 0xFF 0x66 0x65 0xF 0x19 0xFF 0xF2 vex amd64->IR: REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0 vex amd64->IR: VEX=0 VEX.L=0 VEX.n=0x0 ESC=NONE vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=0 ==13161== valgrind: Unrecognised instruction at address 0x401144. ==13161==at 0x401144: main (cet_nops.c:42) ==13161== Your program just tried to execute an instruction that Valgrind ==13161== did not recognise. There are two possible reasons for this. ==13161== 1. Your program has a bug and erroneously jumped to a non-code ==13161==location. If you are running Memcheck and you just saw a ==13161==warning about a bad jump, it's probably your program's fault. ==13161== 2. The instruction is legitimate but Valgrind doesn't handle it, ==13161==i.e. it's Valgrind's fault. If you think this is the case or ==13161==you are not sure, please let us know and we'll try to fix it. ==13161== Either way, Valgrind will now raise a SIGILL signal which will ==13161== probably kill your program. ==13161== ==13161== Process terminating with default action of signal 4 (SIGILL): dumping core ==13161== Illegal opcode at address 0x401144 ==13161==at 0x401144: main (cet_nops.c:42) ==13161== ./vg-in-place: line 29: 13161: Illegal instruction(coredump) Illegal Instruction (core dumped) ./vg-in-place --version -v valgrind-3.13.0.SVN-16420-vex-3384 $ gcc --version gcc (GCC) 5.4.0 Copyright (C) 2015 Free Software Foundation, Inc. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 379966] WARNING: unhandled amd64-linux syscall: 313 (finit_module)
https://bugs.kde.org/show_bug.cgi?id=379966 Ivo Raisr <iv...@ivosh.net> changed: What|Removed |Added CC||iv...@ivosh.net Ever confirmed|0 |1 Status|UNCONFIRMED |CONFIRMED --- Comment #5 from Ivo Raisr <iv...@ivosh.net> --- It means the syscall wrapper needs a careful review w.r.t. kernel sources and ideally also a test case. -- 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 #19 from Ivo Raisr <iv...@ivosh.net> --- And follow up VEX commit in SVN r3376. -- 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 #18 from Ivo Raisr <iv...@ivosh.net> --- Follow up fix in SVN r16393. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 379895] clock_gettime does not execute POST syscall wrapper
https://bugs.kde.org/show_bug.cgi?id=379895 --- Comment #7 from Ivo Raisr <iv...@ivosh.net> --- Good idea. Would be better to have patches upstream than sitting in your computer. If you are missing something for Solaris, let me know or create bugs. Syscall wrappers tend to be the easy part... -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 379895] clock_gettime does not execute POST syscall wrapper
https://bugs.kde.org/show_bug.cgi?id=379895 --- Comment #5 from Ivo Raisr <iv...@ivosh.net> --- A funny bug, indeed! As regards the syscalls you implemented - is that something to be integrated, yet? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 379895] clock_gettime does not execute POST syscall wrapper
https://bugs.kde.org/show_bug.cgi?id=379895 --- Comment #3 from Ivo Raisr <iv...@ivosh.net> --- Thank you for the reproducer, it made fixing this bug really fast! -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 379895] clock_gettime does not execute POST syscall wrapper
https://bugs.kde.org/show_bug.cgi?id=379895 Ivo Raisr <iv...@ivosh.net> changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #2 from Ivo Raisr <iv...@ivosh.net> --- Committed in Valgrind SVN as r16392. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 379895] clock_gettime does not execute POST syscall wrapper
https://bugs.kde.org/show_bug.cgi?id=379895 Ivo Raisr <iv...@ivosh.net> changed: What|Removed |Added Summary|clock_gettime CLOCK_HIGHRES |clock_gettime does not |returns uninitialized |execute POST syscall |timespec. |wrapper -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 379895] clock_gettime CLOCK_HIGHRES returns uninitialized timespec.
https://bugs.kde.org/show_bug.cgi?id=379895 Ivo Raisr <iv...@ivosh.net> changed: What|Removed |Added Assignee|jsew...@acm.org |iv...@ivosh.net CC||iv...@ivosh.net Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #1 from Ivo Raisr <iv...@ivosh.net> --- POST syscall wrapper for clock_gettime was not executed because it was not hooked: - SOLX_(__NR_clock_gettime,sys_clock_gettime), /* 191 */ + SOLXY(__NR_clock_gettime,sys_clock_gettime), /* 191 */ -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 368529] Android arm target link error, missing atexit and pthread_atfork
https://bugs.kde.org/show_bug.cgi?id=368529 Ivo Raisr <iv...@ivosh.net> changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #11 from Ivo Raisr <iv...@ivosh.net> --- Committed in Valgrind SVN as r16384. Thank you for the patch. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 374963] increase valgrind's load address to prevent mmap failure
https://bugs.kde.org/show_bug.cgi?id=374963 Ivo Raisr <iv...@ivosh.net> changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Ivo Raisr <iv...@ivosh.net> --- Committed in Valgrind SVN as r16383. -- 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 Ivo Raisr <iv...@ivosh.net> changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #45 from Ivo Raisr <iv...@ivosh.net> --- We are very close to a new Valgrind release. So at this point I will close this particular bug. Please feel free to create a new one and we will work there. -- 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 #44 from Ivo Raisr <iv...@ivosh.net> --- (In reply to Tamara Vlahovic from comment #43) Thank you for the patch. Committed in VEX SVN as r3372. -- 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 Ivo Raisr <iv...@ivosh.net> changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |CONFIRMED --- Comment #10 from Ivo Raisr <iv...@ivosh.net> --- Unfortunately I do not have a machine with >32 GB of physical memory where I can install Solaris and try it out. Solaris does not overcommit when allocating memory. Regression tests passed ok. -- 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 Ivo Raisr <iv...@ivosh.net> changed: What|Removed |Added Attachment #105549|0 |1 is obsolete|| --- Comment #9 from Ivo Raisr <iv...@ivosh.net> --- Created attachment 105561 --> https://bugs.kde.org/attachment.cgi?id=105561=edit Proposed fix (so far, Linux and Solaris only) Solaris changes. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 374963] increase valgrind's load address to prevent mmap failure
https://bugs.kde.org/show_bug.cgi?id=374963 --- Comment #6 from Ivo Raisr <iv...@ivosh.net> --- Created attachment 105560 --> https://bugs.kde.org/attachment.cgi?id=105560=edit patch to increase load address for almost all platforms to 0x5800 (v2) The previous patch forgot to change suggested client stack end on Solaris. This is now rectified. -- 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 #42 from Ivo Raisr <iv...@ivosh.net> --- (In reply to Tamara Vlahovic from comment #41) Indeed, thank you for spotting it. I think it was caused by a mismerge from TileGX port removal. Commited as SVN r16377. -- 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 Ivo Raisr <iv...@ivosh.net> changed: What|Removed |Added CC||iv...@ivosh.net --- Comment #16 from Ivo Raisr <iv...@ivosh.net> --- Running the latest Valgrind on regression test fb_test_amd64 built with gcc 5.4.0 gives the following crash: vex amd64->IR: unhandled instruction bytes: 0x66 0x4D 0xF 0x38 0xF6 0xC5 0x9C 0x58 0x48 0x83 vex amd64->IR: REX=1 REX.W=1 REX.R=1 REX.X=0 REX.B=1 vex amd64->IR: VEX=0 VEX.L=0 VEX.n=0x0 ESC=0F38 vex amd64->IR: PFX.66=1 PFX.F2=0 PFX.F3=0 ==1119== valgrind: Unrecognised instruction at address 0x409768. ==1119==at 0x409768: exec_adcx (fb_test_amd64.h:69) ==1119==by 0x409806: test_adcx (fb_test_amd64.h:166) ==1119==by 0x411652: main (fb_test_amd64.c:1201) Disassembly indeed shows it is adcx: 0x00409767 <+405>: popfq => 0x00409768 <+406>: adcx %r13,%r8 0x0040976e <+412>: pushfq (gdb) x/16xb 0x409768 0x409768 <exec_adcx+406>: 0x660x4d0x0f0x380xf60xc5 0x9c0x58 0x409770 <exec_adcx+414>: 0x480x830xec0x080x250xd5 0x080x00 ./vg-in-place --version -v valgrind-3.13.0.SVN-16374-vex-3369 Is it possible that some paths in adcx decoding are not handled properly? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 378430] www: update Valgrind alias mirrors
https://bugs.kde.org/show_bug.cgi?id=378430 Ivo Raisr <iv...@ivosh.net> changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #1 from Ivo Raisr <iv...@ivosh.net> --- Commited in Valgrind www SVN as r520. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 379838] disAMode(x86): not an addr!
https://bugs.kde.org/show_bug.cgi?id=379838 Ivo Raisr <iv...@ivosh.net> changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #5 from Ivo Raisr <iv...@ivosh.net> --- VEX SVN commit r3370. Valgrind SVN commit 16375. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 374963] increase valgrind's load address to prevent mmap failure
https://bugs.kde.org/show_bug.cgi?id=374963 --- Comment #5 from Ivo Raisr <iv...@ivosh.net> --- Please test the attached patch [1] which increases the load address for almost all platforms to 0x5800 (from 0x3800). This gives another 512 MB for executable without changing linkage model (which is different on every platform). I've tested on x86/Linux, amd64/Linux, x86/Solaris, amd64/Solaris. 32-bit only, 64-bit only, mix and outer/inner setup. [1] https://bugs.kde.org/attachment.cgi?id=105544 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 374963] increase valgrind's load address to prevent mmap failure
https://bugs.kde.org/show_bug.cgi?id=374963 --- Comment #4 from Ivo Raisr <iv...@ivosh.net> --- Created attachment 105544 --> https://bugs.kde.org/attachment.cgi?id=105544=edit patch to increase load address for almost all platforms to 0x5800 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 379838] disAMode(x86): not an addr!
https://bugs.kde.org/show_bug.cgi?id=379838 Ivo Raisr <iv...@ivosh.net> changed: What|Removed |Added Status|UNCONFIRMED |CONFIRMED Ever confirmed|0 |1 --- Comment #4 from Ivo Raisr <iv...@ivosh.net> --- Seems like the offending instruction is 'xend' from __pthread_rwlock_unlock(). -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 379838] disAMode(x86): not an addr!
https://bugs.kde.org/show_bug.cgi?id=379838 Ivo Raisr <iv...@ivosh.net> changed: What|Removed |Added CC||iv...@ivosh.net --- Comment #1 from Ivo Raisr <iv...@ivosh.net> --- The problem is reproducible even with 'none' tool: $ ./vg-in-place --tool=none helgrind/tests/tc12_rwl_trivial ==29554== Nulgrind, the minimal Valgrind tool ==29554== Copyright (C) 2002-2017, and GNU GPL'd, by Nicholas Nethercote. ==29554== Using Valgrind-3.13.0.SVN and LibVEX; rerun with -h for copyright info ==29554== Command: helgrind/tests/tc12_rwl_trivial ==29554== vex: the `impossible' happened: disAMode(x86): not an addr! vex storage: T total 26363116 bytes allocated vex storage: P total 384 bytes allocated valgrind: the 'impossible' happened: LibVEX called failure_exit(). host stacktrace: ==29554==at 0x580A62CB: show_sched_status_wrk (m_libcassert.c:355) ==29554==by 0x580A63FD: report_and_quit (m_libcassert.c:426) ==29554==by 0x580A65AC: vgPlain_core_panic_at (m_libcassert.c:502) ==29554==by 0x580A65CA: vgPlain_core_panic (m_libcassert.c:512) ==29554==by 0x58019F6C: failure_exit (m_translate.c:740) ==29554==by 0x580E76B3: vpanic (main_util.c:231) ==29554==by 0x58109C2B: disAMode (guest_x86_toIR.c:1564) ==29554==by 0x58129ECC: disInstr_X86_WRK (guest_x86_toIR.c:15322) ==29554==by 0x5812B761: disInstr_X86 (guest_x86_toIR.c:15456) ==29554==by 0x580FE930: bb_to_IR (guest_generic_bb_to_IR.c:365) ==29554==by 0x580E4ACF: LibVEX_FrontEnd (main_main.c:558) ==29554==by 0x580E5302: LibVEX_Translate (main_main.c:1173) ==29554==by 0x5801C827: vgPlain_translate (m_translate.c:1791) ==29554==by 0x58053368: handle_chain_me (scheduler.c:1084) ==29554==by 0x58055067: vgPlain_scheduler (scheduler.c:1428) ==29554==by 0x58065DB7: run_a_thread_NORETURN (syswrap-linux.c:103) sched status: running_tid=1 Thread 1: status = VgTs_Runnable (lwpid 29554) ==29554==at 0x485F818: pthread_rwlock_unlock (pthread_rwlock_unlock.c:38) ==29554==by 0x10891F: safe_pthread_rwlock_unlock (safe-pthread.h:58) ==29554==by 0x108AF9: main (tc12_rwl_trivial.c:29) -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 379838] New: disAMode(x86): not an addr!
https://bugs.kde.org/show_bug.cgi?id=379838 Bug ID: 379838 Summary: disAMode(x86): not an addr! Product: valgrind Version: 3.13 SVN Platform: Compiled Sources OS: Linux Status: UNCONFIRMED Severity: crash Priority: NOR Component: vex Assignee: jsew...@acm.org Reporter: iv...@ivosh.net Target Milestone: --- Running DRD or Helgrind on test case helgrind/tests/tc12_rwl_trivial compiled in 32-bit mode (X86) produces the following crash: $ ./vg-in-place --tool=helgrind helgrind/tests/tc12_rwl_trivial ==29388== Helgrind, a thread error detector ==29388== Copyright (C) 2007-2017, and GNU GPL'd, by OpenWorks LLP et al. ==29388== Using Valgrind-3.13.0.SVN and LibVEX; rerun with -h for copyright info ==29388== Command: helgrind/tests/tc12_rwl_trivial ==29388== ==29388== ---Thread-Announcement-- ==29388== ==29388== Thread #1 is the program's root thread ==29388== ==29388== ==29388== ==29388== Thread #1 unlocked a not-locked lock at 0xFEA5ADEC ==29388==at 0x48333AB: pthread_rwlock_unlock_WRK (hg_intercepts.c:2540) ==29388==by 0x4834D7C: pthread_rwlock_unlock (hg_intercepts.c:2559) ==29388==by 0x10891F: safe_pthread_rwlock_unlock (safe-pthread.h:58) ==29388==by 0x108AF9: main (tc12_rwl_trivial.c:29) ==29388== Lock at 0xFEA5ADEC was first observed ==29388==at 0x4832D45: pthread_rwlock_init_WRK (hg_intercepts.c:2027) ==29388==by 0x4834D2E: pthread_rwlock_init (hg_intercepts.c:2042) ==29388==by 0x10898D: main (tc12_rwl_trivial.c:18) ==29388== Address 0xfea5adec is on thread #1's stack ==29388== in frame #3, created by main (tc12_rwl_trivial.c:14) ==29388== ==29388== vex: the `impossible' happened: disAMode(x86): not an addr! vex storage: T total 32739272 bytes allocated vex storage: P total 384 bytes allocated valgrind: the 'impossible' happened: LibVEX called failure_exit(). host stacktrace: ==29388==at 0x5802918B: show_sched_status_wrk (m_libcassert.c:355) ==29388==by 0x580292BD: report_and_quit (m_libcassert.c:426) ==29388==by 0x5802946C: panic (m_libcassert.c:502) ==29388==by 0x5802946C: vgPlain_core_panic_at (m_libcassert.c:507) ==29388==by 0x5802948A: vgPlain_core_panic (m_libcassert.c:512) ==29388==by 0x580449FC: failure_exit (m_translate.c:740) ==29388==by 0x581062F3: vpanic (main_util.c:231) ==29388==by 0x5812886B: disAMode (guest_x86_toIR.c:1564) ==29388==by 0x58148B0C: disInstr_X86_WRK (guest_x86_toIR.c:15322) ==29388==by 0x5814A3A1: disInstr_X86 (guest_x86_toIR.c:15456) ==29388==by 0x5811D570: bb_to_IR (guest_generic_bb_to_IR.c:365) ==29388==by 0x5810370F: LibVEX_FrontEnd (main_main.c:558) ==29388==by 0x58103F42: LibVEX_Translate (main_main.c:1173) ==29388==by 0x580472B7: vgPlain_translate (m_translate.c:1791) ==29388==by 0x58082558: handle_chain_me (scheduler.c:1084) ==29388==by 0x58084257: vgPlain_scheduler (scheduler.c:1428) ==29388==by 0x58094FA7: thread_wrapper (syswrap-linux.c:103) ==29388==by 0x58094FA7: run_a_thread_NORETURN (syswrap-linux.c:156) sched status: running_tid=1 Thread 1: status = VgTs_Runnable (lwpid 29388) ==29388==at 0x4873818: _xend (pthread_rwlock_unlock.c:38) ==29388==by 0x4873818: pthread_rwlock_unlock (pthread_rwlock_unlock.c:38) ==29388==by 0x48333DA: pthread_rwlock_unlock_WRK (hg_intercepts.c:2543) ==29388==by 0x4834D7C: pthread_rwlock_unlock (hg_intercepts.c:2559) ==29388==by 0x10891F: safe_pthread_rwlock_unlock (safe-pthread.h:58) ==29388==by 0x108AF9: main (tc12_rwl_trivial.c:29) Note: see also the FAQ in the source distribution. It contains workarounds to several common problems. In particular, if Valgrind aborted or crashed after identifying problems in your program, there's a good chance that fixing those problems will prevent Valgrind aborting or crashing, especially if it happened in m_mallocfree.c. If that doesn't help, please report this bug to: www.valgrind.org In the bug report, send all the above text, the valgrind version, and what OS and version you are using. Thanks. $ file helgrind/tests/tc12_rwl_trivial helgrind/tests/tc12_rwl_trivial: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=f5d2b09e348834b0a9c00c65487771d10f9bbc1f, not stripped $ gcc --version gcc (Ubuntu 6.3.0-12ubuntu2) 6.3.0 20170406 Copyright (C) 2016 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ ./vg-in-place --version -v valgrind-3.13.0.SVN-16373M-vex-3369 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 374963] increase valgrind's load address to prevent mmap failure
https://bugs.kde.org/show_bug.cgi?id=374963 Ivo Raisr <iv...@ivosh.net> changed: What|Removed |Added Assignee|jsew...@acm.org |iv...@ivosh.net Status|CONFIRMED |ASSIGNED -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 368529] Android arm target link error, missing atexit and pthread_atfork
https://bugs.kde.org/show_bug.cgi?id=368529 Ivo Raisr <iv...@ivosh.net> changed: What|Removed |Added Status|CONFIRMED |ASSIGNED --- Comment #7 from Ivo Raisr <iv...@ivosh.net> --- I am a little worried about this condition in the patch: #if defined(ANDROID) && defined(__clang__) Nowhere in Valgrind sources we currently base a decision on naked "ANDROID". It is always this combo (from vki-linux.h): #if defined(VGPV_arm_linux_android) || defined(VGPV_x86_linux_android) \ || defined(VGPV_mips32_linux_android) \ || defined(VGPV_arm64_linux_android) ... #endif /* defined(VGPV_*_linux_android) */ If this patch is really arm-android specific, then it should fold inside existing #if defined(VGP_arm_linux) [at line 2424] ... #endif [at line 2442] with a guard such as: #if defined(VGPV_arm_linux_android) ... #endif No need to "defined(__clang__)". Let me know what is the case here. Please eventually modify the patch and test it on arm. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 379744] disInstr(arm): unhandled instruction: 0xEEBE2AC6 (vcvt.s32.f32)
https://bugs.kde.org/show_bug.cgi?id=379744 Ivo Raisr <iv...@ivosh.net> changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Ivo Raisr <iv...@ivosh.net> --- Next time please do not report bugs against s old releases - ideally try with sources compiled from source repository. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 379744] disInstr(arm): unhandled instruction: 0xEEBE2AC6 (vcvt.s32.f32)
https://bugs.kde.org/show_bug.cgi?id=379744 Ivo Raisr <iv...@ivosh.net> changed: What|Removed |Added Summary|disInstr(arm): unhandled|disInstr(arm): unhandled |instruction: 0xEEBE2AC6 |instruction: 0xEEBE2AC6 |(valgrind-3.9.0)|(vcvt.s32.f32) -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 368529] Android arm target link error, missing atexit and pthread_atfork
https://bugs.kde.org/show_bug.cgi?id=368529 Ivo Raisr <iv...@ivosh.net> changed: What|Removed |Added Assignee|jsew...@acm.org |iv...@ivosh.net CC||iv...@ivosh.net Status|UNCONFIRMED |CONFIRMED Ever confirmed|0 |1 --- Comment #6 from Ivo Raisr <iv...@ivosh.net> --- I will have a look. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 379748] [PATCH] Missing pselect syscall (OS X 10.12)
https://bugs.kde.org/show_bug.cgi?id=379748 Ivo Raisr <iv...@ivosh.net> changed: What|Removed |Added CC||iv...@ivosh.net --- Comment #1 from Ivo Raisr <iv...@ivosh.net> --- POSIX does not mandate pselect kernel interface; it mandates only pselect system (library) interface. Therefore placing pselect syscall wrapper in syswrap-generic. is not very fortunate. Have a look at other OSes and their kernel interfaces - Linux has pselect6, Solaris has no pselect at all (libc bases it directly on ppoll). Only *BSD seems to have the same kernel interface as OS X does. -- 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 #40 from Ivo Raisr <iv...@ivosh.net> --- (In reply to Tamara Vlahovic from comment #38) I've had a look at patch for x87 stuff. While passing Fpu_State* instead of UChar* is a good idea, on the other hand changing UChar[80] to UShort[40] is not a very good idead, though. As you are aware, the real x87 layout contains 8 registers per 80 bits (10 bytes). So it is hard to express 80 bits as a natural C type; and that is the reason why UChar[80] was chosen. In addition to that, Fpu_State_16 still contains UChar[80], leading to confusion. I don't know if there is a good/straightforward way how to mitigate warnings for reg[80]. Perhaps some kind of union? If you are not sure, then split the patch and I will take in Fpu_State* stuff while you can work on reg[80] part. -- 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 #39 from Ivo Raisr <iv...@ivosh.net> --- (In reply to Tamara Vlahovic from comment #37) Committed in Valgrind SVN as r16368. Thank you for the patch. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 379744] disInstr(arm): unhandled instruction: 0xEEBE2AC6 (valgrind-3.9.0)
https://bugs.kde.org/show_bug.cgi?id=379744 Ivo Raisr <iv...@ivosh.net> changed: What|Removed |Added CC||iv...@ivosh.net --- Comment #1 from Ivo Raisr <iv...@ivosh.net> --- Please could you supply the unhandled instruction name? You can use objdump or gdb, for example. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 362223] assertion failed when .valgrindrc is a directory instead of a file
https://bugs.kde.org/show_bug.cgi?id=362223 --- Comment #15 from Ivo Raisr <iv...@ivosh.net> --- Follow up commit SVN r16366. -- 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 #36 from Ivo Raisr <iv...@ivosh.net> --- (In reply to Tamara Vlahovic from comment #35) Committed in Valgrind SVN as r16365. Nice approach, thank you for the patch. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 362223] assertion failed when .valgrindrc is a directory instead of a file
https://bugs.kde.org/show_bug.cgi?id=362223 Ivo Raisr <iv...@ivosh.net> changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #14 from Ivo Raisr <iv...@ivosh.net> --- Committed in Valgrind SVN as r16364. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 362223] assertion failed when .valgrindrc is a directory instead of a file
https://bugs.kde.org/show_bug.cgi?id=362223 Ivo Raisr <iv...@ivosh.net> changed: What|Removed |Added Status|CONFIRMED |ASSIGNED -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 362223] assertion failed when .valgrindrc is a directory instead of a file
https://bugs.kde.org/show_bug.cgi?id=362223 --- Comment #12 from Ivo Raisr <iv...@ivosh.net> --- Created attachment 105438 --> https://bugs.kde.org/attachment.cgi?id=105438=edit proposed patch -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 360429] unhandled ioctl 0x530d with no size/direction hints (CDROMREADMODE1)
https://bugs.kde.org/show_bug.cgi?id=360429 Ivo Raisr <iv...@ivosh.net> changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Ivo Raisr <iv...@ivosh.net> --- Committed in Valgrind SVN as r16358. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 360429] unhandled ioctl 0x530d with no size/direction hints (CDROMREADMODE1)
https://bugs.kde.org/show_bug.cgi?id=360429 Ivo Raisr <iv...@ivosh.net> changed: What|Removed |Added Status|CONFIRMED |ASSIGNED --- Comment #2 from Ivo Raisr <iv...@ivosh.net> --- The attached patch is missing definition for VKI_CDROMREADMODE1. However it's obvious so I've added it at the right place in vki-linux.h. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 362223] assertion failed when .valgrindrc is a directory instead of a file
https://bugs.kde.org/show_bug.cgi?id=362223 Ivo Raisr <iv...@ivosh.net> changed: What|Removed |Added Assignee|jsew...@acm.org |iv...@ivosh.net -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 360429] unhandled ioctl 0x530d with no size/direction hints (CDROMREADMODE1)
https://bugs.kde.org/show_bug.cgi?id=360429 Ivo Raisr <iv...@ivosh.net> changed: What|Removed |Added Summary|Warning: noted but |unhandled ioctl 0x530d with |unhandled ioctl 0x530d with |no size/direction hints |no size/direction hints.|(CDROMREADMODE1) -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 360429] Warning: noted but unhandled ioctl 0x530d with no size/direction hints.
https://bugs.kde.org/show_bug.cgi?id=360429 Ivo Raisr <iv...@ivosh.net> changed: What|Removed |Added Assignee|jsew...@acm.org |iv...@ivosh.net Status|UNCONFIRMED |CONFIRMED Ever confirmed|0 |1 CC||iv...@ivosh.net -- 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 #34 from Ivo Raisr <iv...@ivosh.net> --- I am afraid I don't see how the latest patch for syswrap-generic.c improves the situation. On sparc64/Linux, I see the following warnings (line numbers are approximate but you get the idea): m_syswrap/syswrap-generic.c: In function ‘inet6_format’: m_syswrap/syswrap-generic.c:702:11: warning: cast increases required alignment of target type [-Wcast-align] (const struct vki_in_addr *)(ip + 12); ^ m_syswrap/syswrap-generic.c: In function ‘pre_mem_read_sockaddr’: m_syswrap/syswrap-generic.c:1119:36: warning: cast increases required alignment of target type [-Wcast-align] struct vki_sockaddr_in* sin = (struct vki_sockaddr_in *)sa; ^ m_syswrap/syswrap-generic.c:1120:36: warning: cast increases required alignment of target type [-Wcast-align] struct vki_sockaddr_in6* sin6 = (struct vki_sockaddr_in6 *)sa; ^ m_syswrap/syswrap-generic.c:1125:36: warning: cast increases required alignment of target type [-Wcast-align] struct vki_sockaddr_nl* nl = (struct vki_sockaddr_nl *)sa; If my understanding is correct then your patch deals just with the first occurrence. And why is ipv6 now an array of 4 x UInt? This does not make much sense - IPv6 is just 16 bytes, usually displayed per hextets [1]. Could you: - Deal with all 4 occurrences - Use for example ASSUME_ALIGNED for the casts? [1] https://en.wikipedia.org/wiki/IPv6_address -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 373086] Implement additional Xen hypercalls
https://bugs.kde.org/show_bug.cgi?id=373086 Ivo Raisr <iv...@ivosh.net> changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Ivo Raisr <iv...@ivosh.net> --- Thank you for the patch. Committed in Valgrind SVN as r16355. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 377891] Update Xen 4.6 domctl wrappers
https://bugs.kde.org/show_bug.cgi?id=377891 Ivo Raisr <iv...@ivosh.net> changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #1 from Ivo Raisr <iv...@ivosh.net> --- Thank you for the patch. Committed in Valgrind SVN as r16354. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 373086] Implement additional Xen hypercalls
https://bugs.kde.org/show_bug.cgi?id=373086 Ivo Raisr <iv...@ivosh.net> changed: What|Removed |Added Assignee|jsew...@acm.org |iv...@ivosh.net Status|UNCONFIRMED |CONFIRMED CC||iv...@ivosh.net Ever confirmed|0 |1 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 377891] Update Xen 4.6 domctl wrappers
https://bugs.kde.org/show_bug.cgi?id=377891 Ivo Raisr <iv...@ivosh.net> changed: What|Removed |Added CC||iv...@ivosh.net Ever confirmed|0 |1 Assignee|jsew...@acm.org |iv...@ivosh.net Status|UNCONFIRMED |CONFIRMED -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 377066] Some Valgrind unit tests fail to compile on Ubuntu 16.10 with PIE enabled by default
https://bugs.kde.org/show_bug.cgi?id=377066 Ivo Raisr <iv...@ivosh.net> changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Ivo Raisr <iv...@ivosh.net> --- Committed in Valgrind SVN as r16349. -- 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 Ivo Raisr <iv...@ivosh.net> changed: What|Removed |Added Status|CONFIRMED |ASSIGNED --- Comment #31 from Ivo Raisr <iv...@ivosh.net> --- Another patch committed in SVN r16348. -- 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 Ivo Raisr <iv...@ivosh.net> changed: What|Removed |Added CC||m...@cyrilbouvier.fr --- Comment #13 from Ivo Raisr <iv...@ivosh.net> --- *** Bug 372828 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 372828] vex amd64->IR: unhandled instruction bytes: 0x66 0x4D 0xF 0x38 0xF6 0xD2 0x66 0x4D (adcx)
https://bugs.kde.org/show_bug.cgi?id=372828 Ivo Raisr <iv...@ivosh.net> changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #7 from Ivo Raisr <iv...@ivosh.net> --- *** This bug has been marked as a duplicate of bug 360415 *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 372828] vex amd64->IR: unhandled instruction bytes: 0x66 0x4D 0xF 0x38 0xF6 0xD2 0x66 0x4D (adcx)
https://bugs.kde.org/show_bug.cgi?id=372828 Ivo Raisr <iv...@ivosh.net> changed: What|Removed |Added Assignee|jsew...@acm.org |iv...@ivosh.net -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 372828] vex amd64->IR: unhandled instruction bytes: 0x66 0x4D 0xF 0x38 0xF6 0xD2 0x66 0x4D (adcx)
https://bugs.kde.org/show_bug.cgi?id=372828 --- Comment #6 from Ivo Raisr <iv...@ivosh.net> --- This bug is a duplicate of: 360415 amd64 instructions ADCX and ADOX are not implemented in VEX -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 372828] vex amd64->IR: unhandled instruction bytes: 0x66 0x4D 0xF 0x38 0xF6 0xD2 0x66 0x4D (adcx)
https://bugs.kde.org/show_bug.cgi?id=372828 Ivo Raisr <iv...@ivosh.net> changed: What|Removed |Added Summary|vex amd64->IR: unhandled|vex amd64->IR: unhandled |instruction bytes: 0x66 |instruction bytes: 0x66 |0x4D 0xF 0x38 0xF6 0xD2 |0x4D 0xF 0x38 0xF6 0xD2 |0x66 0x4D |0x66 0x4D (adcx) -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 372828] vex amd64->IR: unhandled instruction bytes: 0x66 0x4D 0xF 0x38 0xF6 0xD2 0x66 0x4D (adcx)
https://bugs.kde.org/show_bug.cgi?id=372828 Ivo Raisr <iv...@ivosh.net> changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |CONFIRMED --- Comment #5 from Ivo Raisr <iv...@ivosh.net> --- Yes, it indeed does. Thank you. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 372828] vex amd64->IR: unhandled instruction bytes: 0x66 0x4D 0xF 0x38 0xF6 0xD2 0x66 0x4D
https://bugs.kde.org/show_bug.cgi?id=372828 --- Comment #3 from Ivo Raisr <iv...@ivosh.net> --- For example with objdump: objdump -d /home/x/lib/libgmp.so.10.3.1 | grep '66 4d 0f 38 f6 d2 66 4d' and the instruction name should be right after the byte sequence. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 379630] false positive std::mutex problems
https://bugs.kde.org/show_bug.cgi?id=379630 Ivo Raisr <iv...@ivosh.net> changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |CONFIRMED --- Comment #5 from Ivo Raisr <iv...@ivosh.net> --- Yes, compilation options make a huge difference. I can reproduce the problem now. DRD with '--trace-mutex=yes' reports this: ... m1=0xffefffc00, m2=0xffefffc28 ==23335== [1] mutex_trylock mutex 0xffefffc00 rc 0 owner 0 ==23335== [1] post_mutex_lock mutex 0xffefffc00 rc 0 owner 0 ==23335== [1] mutex_trylock mutex 0xffefffc28 rc 0 owner 0 ==23335== [1] post_mutex_lock mutex 0xffefffc28 rc 0 owner 0 ==23335== [1] mutex_unlockmutex 0xffefffc28 rc 1 ==23335== [1] mutex_unlockmutex 0xffefffc00 rc 1 m2=0xffefffc00, m1=0xffefffc28 ==23335== [1] mutex_trylock mutex 0xffefffc28 rc 0 owner 1 ==23335== [1] post_mutex_lock mutex 0xffefffc28 rc 0 owner 1 ==23335== [1] mutex_trylock mutex 0xffefffc00 rc 0 owner 1 ==23335== [1] post_mutex_lock mutex 0xffefffc00 rc 0 owner 1 ==23335== [1] mutex_unlockmutex 0xffefffc00 rc 1 ==23335== [1] mutex_unlockmutex 0xffefffc28 rc 1 And Helgrind built with "SHOW_EVENTS 1" reports this: m1=0xffefffc10, m2=0xffefffc38 evh__hg_PTHREAD_MUTEX_LOCK_PRE(ctid=1, mutex=0xFFEFFFC10) evh__HG_PTHREAD_MUTEX_LOCK_POST(ctid=1, mutex=0xFFEFFFC10) evh__hg_PTHREAD_MUTEX_LOCK_PRE(ctid=1, mutex=0xFFEFFFC38) evh__HG_PTHREAD_MUTEX_LOCK_POST(ctid=1, mutex=0xFFEFFFC38) evh__HG_PTHREAD_MUTEX_UNLOCK_PRE(ctid=1, mutex=0xFFEFFFC38) evh__hg_PTHREAD_MUTEX_UNLOCK_POST(ctid=1, mutex=0xFFEFFFC38) evh__HG_PTHREAD_MUTEX_UNLOCK_PRE(ctid=1, mutex=0xFFEFFFC10) evh__hg_PTHREAD_MUTEX_UNLOCK_POST(ctid=1, mutex=0xFFEFFFC10) m2=0xffefffc10, m1=0xffefffc38 evh__hg_PTHREAD_MUTEX_LOCK_PRE(ctid=1, mutex=0xFFEFFFC38) evh__HG_PTHREAD_MUTEX_LOCK_POST(ctid=1, mutex=0xFFEFFFC38) evh__hg_PTHREAD_MUTEX_LOCK_PRE(ctid=1, mutex=0xFFEFFFC10) evh__HG_PTHREAD_MUTEX_LOCK_POST(ctid=1, mutex=0xFFEFFFC10) evh__HG_PTHREAD_MUTEX_UNLOCK_PRE(ctid=1, mutex=0xFFEFFFC10) evh__hg_PTHREAD_MUTEX_UNLOCK_POST(ctid=1, mutex=0xFFEFFFC10) evh__HG_PTHREAD_MUTEX_UNLOCK_PRE(ctid=1, mutex=0xFFEFFFC38) evh__hg_PTHREAD_MUTEX_UNLOCK_POST(ctid=1, mutex=0xFFEFFFC38) So both tools correctly detect mutex lock and unlock. DRD does not report lock order violation, although it could have. As regards detecting when mutex is allocated or not. The reproducer unfortunately does not invoke none of pthread_mutex_init() or pthread_mutex_destroy(). If you disassemble the resulting binary, you'll see calls to gthread_mutex_lock() and gthread_mutex_unlock(). However no calls to init or destroy - they are implicit. At this point I think you need to teach your program to annotate for this. See Valgrind manual [1] and also these hints [2]. [1] http://valgrind.org/docs/manual/drd-manual.html#drd-manual.C++11 [2] http://valgrind.org/docs/manual/hg-manual.html#hg-manual.effective-use -- 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 #29 from Ivo Raisr <iv...@ivosh.net> --- Thank you for another patch. I've modified it slightly in VG_(memset)() and tested successfully on sparcv9/Linux. -- 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 Ivo Raisr <iv...@ivosh.net> changed: What|Removed |Added Attachment #105392|0 |1 is obsolete|| --- Comment #28 from Ivo Raisr <iv...@ivosh.net> --- Created attachment 105406 --> https://bugs.kde.org/attachment.cgi?id=105406=edit slightly modified patch for m_libcbase.c -- You are receiving this mail because: You are watching all bug changes.
