[valgrind] [Bug 405205] tests/filter_libc: remove the line holding the futex syscall error entirely
https://bugs.kde.org/show_bug.cgi?id=405205 --- Comment #1 from Stefan Maksimovic --- Did anyone have a chance to take a look at this? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 406355] mcsignopass and mcsigpass fails due to a slight difference in gdb output
https://bugs.kde.org/show_bug.cgi?id=406355
Stefan Maksimovic changed:
What|Removed |Added
CC||stefan.maksimo...@rt-rk.com
--- Comment #1 from Stefan Maksimovic ---
Created attachment 119331
--> https://bugs.kde.org/attachment.cgi?id=119331&action=edit
Generic substitution, MIPS changes
Hello Alexandra,
I have an exact problem as yours, the difference being there was an another
test involved, namely gdbserver_tests/mcbreak.
--- mcbreak.stdoutB.exp 2019-02-13 14:31:47.0 +0100
+++ mcbreak.stdoutB.out 2019-04-04 13:16:30.0 +0200
@@ -43,11 +43,11 @@
Delete all breakpoints? (y or n) [answered Y; input not from terminal]
Continuing.
Program received signal SIGTRAP, Trace/breakpoint trap.
-0x in make_error (s=0x "called from level") at t.c:41
+make_error (s=0x "called from level") at t.c:41
41 if (int_und == 0)
44 printf ("%s int_und is not zero\n", s);
old_pc has changed after step
Continuing.
Program received signal SIGTRAP, Trace/breakpoint trap.
-0x in make_error (s=0x "called from main") at t.c:41
+make_error (s=0x "called from main") at t.c:41
41 if (int_und == 0)
Could you alter your patch do substitutions globally instead of being tied to
gdbserver_tests/mcsignopass
and
gdbserver_tests/mcsigpass
tests specifically?
Something along the lines of 's/0x in \([^\s]+\)/\1/' ?
I've attached a patch which works for me, could you check if it works for you
as well?
If so, would it be possible for you to include my changes in your patch?
Details:
mips64r2 LE
Linux 3.7.10
glibc 2.28
gcc 8.2.0
gdb 7.11.1
Thanks,
Stefan
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 410599] New: Non-deterministic behaviour of pth_self_kill_15_other test
https://bugs.kde.org/show_bug.cgi?id=410599 Bug ID: 410599 Summary: Non-deterministic behaviour of pth_self_kill_15_other test Product: valgrind Version: 3.15 SVN Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: jsew...@acm.org Reporter: stefan.maksimo...@rt-rk.com CC: mips3...@gmail.com Target Milestone: --- A recent commit https://sourceware.org/git/?p=valgrind.git;a=commit;h=63a9f0793113fd5d828ea7b6183812ad71f924f1 has introduced a test which exhibits different behaviour on some platforms. Namely, running the pth_self_kill_15_other test on these can end in either of the following: 1) the spawned thread finishes first 2) the main thread finishes first Running the test multiple times in succession we observed that on x86 the test finishes as described in the 2) case whereas on others either of the two cases can be present. We have seen this behaviour on different arm and mips platforms. In the 2) case the output we get corresponds with the .exp file while in the 1) case we get an extra 'Terminated' string from the kernel on stderr. Moreover, we ran the test on arm/mips without the functionality the rest of that patch provides, to test whether it really hangs/loops on arm/mips or not. Interestingly the pth_self_kill_9 test behaves the same on arm/mips and x86 whereas the pth_self_kill_15_other does finish on arm/mips (it prints the 'Terminated' message - the spawned thread finishes first). A possible solution would be to make the test deterministic; one way would consist of inserting a pthread_join call. That would alter the test in terms of the output produced but we believe that the nature of the test itself would remain intact. Reading the commit message which introduced the tests, we gather that the purpose was to test two scenarios(loop/hang) which the commit was created to solve. In case the above suggested change would not disrupt the intended functionality of the test, would it be applicable? What course of action would you recommend? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 405205] New: tests/filter_libc: remove the line holding the futex syscall error entirely
https://bugs.kde.org/show_bug.cgi?id=405205
Bug ID: 405205
Summary: tests/filter_libc: remove the line holding the futex
syscall error entirely
Product: valgrind
Version: 3.15 SVN
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: jsew...@acm.org
Reporter: stefan.maksimo...@rt-rk.com
CC: mips3...@gmail.com
Target Milestone: ---
Created attachment 118641
--> https://bugs.kde.org/attachment.cgi?id=118641&action=edit
Proposed solution
SUMMARY
At the moment the message reported by glibc is removed by the perl substitute
command, leaving an empty line it its place.
This change alters tests/filter_libc so as to remove the line containing the
futex error message completely; effectively we skip printing the line
altogether.
Need for this arose when observing a build process initiated by a buildbot, in
which case the 'make regtest' command was invoked via ssh.
In that case a terminal isn't spawned so the abovementioned message is printed
to stderr which gets filtered by tests/filter_libc (cf. building valgrind
regularly; the message is printed directly to the terminal, not stderr, hence
does not get filtered).
After this change no empty line is printed instead of the message, so there are
no conflicts with the existing stderr.exp files for the
helgrind/tests/{tc18_semabuse,tc20_verifywrap}.
These two tests were the ones where the stderr failure was observed.
I did not observe any regressions for mips32, mips64 or x86 after this change.
STEPS TO REPRODUCE
1. Run either a single test or 'make regtest' via ssh remotely
2. Run the same command locally
3. Observe the difference in the futex syscall error message being printed to
stderr in the first case, whereas it is printed directly to the terminal in the
second case for the two tests mentioned
OBSERVED RESULT
An additional newline appears in the tc18_semabuse and tc20_verifywrap
stderr.out files
EXPECTED RESULT
No empty line generated
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 410599] Non-deterministic behaviour of pth_self_kill_15_other test
https://bugs.kde.org/show_bug.cgi?id=410599 --- Comment #2 from Stefan Maksimovic --- Created attachment 122034 --> https://bugs.kde.org/attachment.cgi?id=122034&action=edit pth_self_kill.patch Here's our attempt at making the test deterministic: We decided on using a pthread_join call where the main thread would wait for the spawned one. This had it's shortcomings as it did not work for the pth_self_kill_15_other case. To work around this we made the spawned thread to wait for the parent by modifying the signal handler for SIGTERM, since that was the case which did not work for our previous attempt. With this we managed to both reproduce the loop/hang case without the commit mentioned in the bug description and to run the test without those problems with the commit on x86. If it's not too much trouble, I suggest you test it yourself just to make sure. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 410757] New: glibc wrapper discrepancy for preadv2/pwritev2 system calls across different versions
https://bugs.kde.org/show_bug.cgi?id=410757 Bug ID: 410757 Summary: glibc wrapper discrepancy for preadv2/pwritev2 system calls across different versions Product: valgrind Version: 3.15 SVN Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: jsew...@acm.org Reporter: stefan.maksimo...@rt-rk.com CC: mips3...@gmail.com Target Milestone: --- Running the memcheck/tests/linux/sys-preadv2_pwritev2 test on a system with glibc v2.27 and v2.28 we experienced a failure which manifested itself in additional output on stderr. Namely, in addition to the expected output for the preadv2/pwritev2 calls stderr contained output for preadv/pwritev calls as well. The wrappers pertaining to v2.27 and v2.28 trigger a call to preadv/pwritev which produce the extra output. Inspecting a bit further we found out that the above was due to the changes for the preadv2/pwritev2 system call wrappers inside glibc. The versions which do not differ are 2.26 and 2.29. Those on the other hand differ from the versions 2.27 and 2.28. The difference can be easily observed here: https://elixir.bootlin.com/glibc/glibc-2.27/source/sysdeps/unix/sysv/linux/preadv2.c (it concerns the if statement which checks the return value of SYSCALL_CANCEL). I presume this should be handled using either a separate .exp or a suppression file. Would the latter be the way to go? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 410599] Non-deterministic behaviour of pth_self_kill_15_other test
https://bugs.kde.org/show_bug.cgi?id=410599 --- Comment #4 from Stefan Maksimovic --- Created attachment 122077 --> https://bugs.kde.org/attachment.cgi?id=122077&action=edit pth_self_kill.patch v2 Thanks Philippe, validating the test through memcheck slipped my mind. I've updated the patch by initializing the variables reported by memcheck, it should be fine now. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 410757] glibc wrapper discrepancy for preadv2/pwritev2 system calls across different versions
https://bugs.kde.org/show_bug.cgi?id=410757 --- Comment #2 from Stefan Maksimovic --- Created attachment 122172 --> https://bugs.kde.org/attachment.cgi?id=122172&action=edit preadv2/pwritev2 check Thanks for the suggestion Mark, Initially we tried using the approach you described but that did not suffice for the machine we encountered this problem on. It seems that __NR_preadv2 and __NR_prwitev2 can be defined in unistd.h despite the kernel not supporting those system calls. This suggests that the defines in unistd.h are maintained by the current glibc installation I presume? Searching for __NR_preadv2 and __NR_prwitev2 in unistd.h on a machine with an older glibc version gave no results. Instead of just checking for__NR_preadv2/__NR_prwitev2 presence like the membarrier test did, we opted to write a test which would issue a syscall and subsequently check if the error code was set to ENOSYS. This works fine in our case but it required to use an AC_RUN_IFELSE directive which will pose a problem in case of cross compilation as the test program will most likely not run at configure time. With this drawback in mind, would this solution be acceptable? If not, is there an another way to check for syscall support in the kernel without the need to actually run the test program at configure time? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 410757] glibc wrapper discrepancy for preadv2/pwritev2 system calls across different versions
https://bugs.kde.org/show_bug.cgi?id=410757 --- Comment #4 from Stefan Maksimovic --- Created attachment 122182 --> https://bugs.kde.org/attachment.cgi?id=122182&action=edit preadv2/pwritev2 runtime prereq check Hello Bart, Thank you for your input; yes, a runtime prerequisite would get rid of the cross compile issue mentioned in the comment above. I've attached a patch which outlines the alternate approach. Let me know what you think. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 416285] New: Use prlimit64 in VG_(getrlimit) and VG_(setrlimit)
https://bugs.kde.org/show_bug.cgi?id=416285 Bug ID: 416285 Summary: Use prlimit64 in VG_(getrlimit) and VG_(setrlimit) Product: valgrind Version: 3.15 SVN Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: jsew...@acm.org Reporter: stefan.maksimo...@rt-rk.com CC: mips3...@gmail.com Target Milestone: --- Created attachment 125143 --> https://bugs.kde.org/attachment.cgi?id=125143&action=edit patch Amend the recent update to VG_(getrlimit) and VG_(setrlimit) [get|set]rlimit system calls are becoming deprecated. Coregrind should use prlimit64 as the first candidate in order to achieve "rlimit" functionality. There are also systems that do not even support older "rlimits". Modify the previously added support VG_(getrlimit) and VG_(setrlimit) using __NR_prlimit64 by making it similar to the glibc implementation. This change has been tested on x86 and mips and we would like feedback on how it behaves on other architectures/systems. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 417187] New: [MIPS] Conditional branch problem since 'grail' changes
https://bugs.kde.org/show_bug.cgi?id=417187 Bug ID: 417187 Summary: [MIPS] Conditional branch problem since 'grail' changes Product: valgrind Version: 3.15 SVN Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: jsew...@acm.org Reporter: stefan.maksimo...@rt-rk.com Target Milestone: --- Created attachment 125689 --> https://bugs.kde.org/attachment.cgi?id=125689&action=edit enable_grail_mips.diff The problem we're having is present since the recent changes from the 'grail' branch have been applied to master. It can be reproduced on a simple program (consists just of the main function that has a return 42; statement). More specifically, it happens even before main is encountered (in the _dl_aux_init function). The attached debug output depicts inconsistent IR which causes the failure: t5 = CmpEQ32(t4,0x0:I32) ... PUT(136) = t5 The number 136 corresponds with the PC register. Valgrind tries to write the result of the compare operation into the PC register. The following is a different observation which may or may not have to do with the problem above: It has to do with conditional branches. Namely, upon hitting such a branch three instructions are analysed for each of those. The problem seems to be having a branch instruction as the last one of those three. Since branch instructions on MIPS have delay slots, the delay slot instruction needs to be analysed before the jump kind can be set to the branch instruction preceding it. As it stands that doesn't happen and the jump instruction gets assigned a jump kind of Ijk_Boring instead of Ijk_Call. See the fall through case after superblock 4 in the attached debug output. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 417187] [MIPS] Conditional branch problem since 'grail' changes
https://bugs.kde.org/show_bug.cgi?id=417187 --- Comment #1 from Stefan Maksimovic --- Created attachment 125690 --> https://bugs.kde.org/attachment.cgi?id=125690&action=edit test program log without grail changes -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 417187] [MIPS] Conditional branch problem since 'grail' changes
https://bugs.kde.org/show_bug.cgi?id=417187 --- Comment #2 from Stefan Maksimovic --- Created attachment 125691 --> https://bugs.kde.org/attachment.cgi?id=125691&action=edit test program log with grail changes -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 417187] [MIPS] Conditional branch problem since 'grail' changes
https://bugs.kde.org/show_bug.cgi?id=417187 Stefan Maksimovic changed: What|Removed |Added Attachment #125690|0 |1 is obsolete|| --- Comment #3 from Stefan Maksimovic --- Created attachment 125692 --> https://bugs.kde.org/attachment.cgi?id=125692&action=edit test program log without grail changes -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 417187] [MIPS] Conditional branch problem since 'grail' changes
https://bugs.kde.org/show_bug.cgi?id=417187 Stefan Maksimovic changed: What|Removed |Added Attachment #125691|0 |1 is obsolete|| --- Comment #4 from Stefan Maksimovic --- Created attachment 125693 --> https://bugs.kde.org/attachment.cgi?id=125693&action=edit test program log with grail changes -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 417187] [MIPS] Conditional branch problem since 'grail' changes
https://bugs.kde.org/show_bug.cgi?id=417187 --- Comment #7 from Stefan Maksimovic --- Thank you for your reply, Julian. We pretty much agree with your analysis of the initial SB sequence as well as the first and second speculative disassembly. A note for the first speculative disassembly: you guessed correctly, the branch at 0x4013C0 does jump back to 0x4013BC. To be a bit more clear, the 16 bit offset of the bne instruction (0xFFFE signed, in this case) is left shifted 2 bits and added to the address following the branch, forming the target address of the jump. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 417187] [MIPS] Conditional branch problem since 'grail' changes
https://bugs.kde.org/show_bug.cgi?id=417187 --- Comment #8 from Stefan Maksimovic --- (In reply to Stefan Maksimovic from comment #7) > Thank you for your reply, Julian. > > We pretty much agree with your analysis of the initial SB sequence as well as > the first and second speculative disassembly. > > A note for the first speculative disassembly: you guessed correctly, > the branch at 0x4013C0 does jump back to 0x4013BC. > > To be a bit more clear, the 16 bit offset of the bne instruction (0xFFFE > signed, in this case) is left shifted 2 bits and added to the address > following the branch, forming the target address of the jump. Quoting the instruction set reference, as I may have provided erroneous information about the bne instruction above: "An 18-bit signed offset (the 16-bit offset field shifted left 2 bits) is added to the address of the instruction following the branch (not the branch itself), in the branch delay slot, to form a PC-relative effective target address." -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 417238] New: Test memcheck/tests/vbit-test fails on mips64 BE
https://bugs.kde.org/show_bug.cgi?id=417238 Bug ID: 417238 Summary: Test memcheck/tests/vbit-test fails on mips64 BE Product: valgrind Version: 3.15 SVN Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: jsew...@acm.org Reporter: stefan.maksimo...@rt-rk.com CC: mips3...@gmail.com Target Milestone: --- Created attachment 125715 --> https://bugs.kde.org/attachment.cgi?id=125715&action=edit proposed solution The problem in question has been discovered on a mips64 BE machine. Proposed solution attached. It consists of using the u32 member variable of the union inside the vbits_t structure instead of the u1 one since the least significant part of u32 does not seem to overlap with u1. Tested on x86 and mips64 BE. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 416285] Use prlimit64 in VG_(getrlimit) and VG_(setrlimit)
https://bugs.kde.org/show_bug.cgi?id=416285 --- Comment #1 from Stefan Maksimovic --- Did anyone have a chance to take a look at this in the meantime? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 417264] New: Musl issues: Fix none/tests/pth_atfork1.c
https://bugs.kde.org/show_bug.cgi?id=417264 Bug ID: 417264 Summary: Musl issues: Fix none/tests/pth_atfork1.c Product: valgrind Version: 3.15 SVN Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: jsew...@acm.org Reporter: stefan.maksimo...@rt-rk.com CC: mips3...@gmail.com Target Milestone: --- Created attachment 125731 --> https://bugs.kde.org/attachment.cgi?id=125731&action=edit proposed solution There is no error.h on some systems (e.g. musl), so use local implementation of error() function as a safe option. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 417266] New: Make memcheck/tests/linux/sigqueue usable with musl
https://bugs.kde.org/show_bug.cgi?id=417266 Bug ID: 417266 Summary: Make memcheck/tests/linux/sigqueue usable with musl Product: valgrind Version: 3.15 SVN Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: jsew...@acm.org Reporter: stefan.maksimo...@rt-rk.com CC: mips3...@gmail.com Target Milestone: --- Created attachment 125733 --> https://bugs.kde.org/attachment.cgi?id=125733&action=edit proposed solution Remove offsetof(siginfo_t, _sifields) from the test. "_sifields" isn't mandatory field of struct siginfo_t so it shouldn't be used in regular user program. There is no functional impact on test. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 417187] [MIPS] Conditional branch problem since 'grail' changes
https://bugs.kde.org/show_bug.cgi?id=417187 Stefan Maksimovic changed: What|Removed |Added Attachment #125689|0 |1 is obsolete|| --- Comment #10 from Stefan Maksimovic --- Created attachment 126199 --> https://bugs.kde.org/attachment.cgi?id=126199&action=edit Newly proposed solution pt 1 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 417187] [MIPS] Conditional branch problem since 'grail' changes
https://bugs.kde.org/show_bug.cgi?id=417187 --- Comment #11 from Stefan Maksimovic --- Created attachment 126200 --> https://bugs.kde.org/attachment.cgi?id=126200&action=edit Newly proposed solution pt 2 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 417187] [MIPS] Conditional branch problem since 'grail' changes
https://bugs.kde.org/show_bug.cgi?id=417187
Stefan Maksimovic changed:
What|Removed |Added
Attachment #125692|0 |1
is obsolete||
Attachment #125693|0 |1
is obsolete||
--- Comment #12 from Stefan Maksimovic ---
Created attachment 126210
--> https://bugs.kde.org/attachment.cgi?id=126210&action=edit
cdebug_zlib logs
An update regarding the proposed approach in the last comment:
We've modified the disInstr_MIPS_WRK function to recursively call itself
in case of a branch instruction.
This has proven itself to be effective, as valgrind now does speculate on
conditional branches which can be seen in the debug output (after the
[proposed solution pt 2] has been applied).
The branches and their delay slots get nicely bundled in a single
8-byte instruction.
This comprises the changes in the [proposed solution pt 1].
A few problems exist though, as there are a couple of tests failing across our
test machines. They appear after the [proposed solution pt 2] patch
has been applied, which enables the speculative execution.
As an example of that, we can take a look at memcheck/tests/cdebug_zlib (its
source, cdebug.c):
int main() {
int x;
if (x) return 1;
return 0;
}
In addition to the existing output in its stderr file, we now have an
additional
message:
Syscall param exit_group(status) contains uninitialised byte(s)
at 0x491A568: _Exit (_exit.c:32)
by 0x48A0E58: __run_exit_handlers (exit.c:97)
by 0x48A0ED8: exit (exit.c:104)
by 0x4881800: (below main) (libc-start.c:321)
We've analysed this for some time, but haven't been able to get to the bottom
of
where the new error originates from, nor do we observe any other architectures
experiencing this kind of failure.
The attached file includes the debug output of the cdebug_zlib test runs.
Any thoughts on this?
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 417187] [MIPS] Conditional branch problem since 'grail' changes
https://bugs.kde.org/show_bug.cgi?id=417187 --- Comment #13 from Stefan Maksimovic --- Created attachment 126427 --> https://bugs.kde.org/attachment.cgi?id=126427&action=edit cdebug_zlib main fn logs, w/ and w/o frame ptr used Another observation: Modifying the main function of memcheck/tests/cdebug.c so as to make the SPEC side exit block differ from the original results in valgrind not doing the &&-transform which in turn does not produce the extra error mentioned in the previous comment. That is because the new side exit block terminates with a PUT($pc) which gets a non-constant value, is that correct? There are two files in the attachment, the shorter one differs from the original in being compiled with -fomit-frame-pointer. I've only left the debug output of the main function, the rest should be the same with only one difference which is the aforementioned error that appears right after the _Exit function: Syscall param exit_group(status) contains uninitialised byte(s) at 0x4919B38: _Exit (_exit.c:31) by 0x489AEA0: __run_exit_handlers (exit.c:98) by 0x489AF4C: exit (exit.c:105) by 0x48804C4: (below main) (libc-start.c:325) Uninitialised value was created by a stack allocation at 0x4005F0: main (cdebug.c:1) Shouldn't the _Exit function receive either 0 or 1 (coming from the return statements) despite the fact that the variable x is uninitialized? Does the transformation somehow propagate x to the _Exit function or does something entirely different happen instead? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 417264] Musl issues: Fix none/tests/pth_atfork1.c
https://bugs.kde.org/show_bug.cgi?id=417264 --- Comment #1 from Stefan Maksimovic --- Did anyone have a chance to take a look at this in the meantime? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 417266] Make memcheck/tests/linux/sigqueue usable with musl
https://bugs.kde.org/show_bug.cgi?id=417266 --- Comment #1 from Stefan Maksimovic --- Did anyone have a chance to take a look at this in the meantime? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 417187] [MIPS] Conditional branch problem since 'grail' changes
https://bugs.kde.org/show_bug.cgi?id=417187 --- Comment #14 from Stefan Maksimovic --- Created attachment 126546 --> https://bugs.kde.org/attachment.cgi?id=126546&action=edit branch special case patch Another update: Analyzing the mips and the x86 debug output side by side we noticed the following: The fallthrough blocks in the main function differ by x86 having an unconditional jump, which when translated to IR results in a single PUT(PC) instruction. Mips on the other hand uses a conditional branch instruction with parameters set so as to always take one of the two paths, making the jump effectively unconditional. By using a conditional branch a conditional PUT(PC) was generated in the IR which enabled the &&-transform to take place, resulting in the outcome described in previous comments. Attached patch modifies this special case of the branch instruction by not generating conditional PUTs to PC. Having applied this change the &&-transform does not take place in the main function, much like in the x86 case. This fixes a number of failing tests on our side. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 417187] [MIPS] Conditional branch problem since 'grail' changes
https://bugs.kde.org/show_bug.cgi?id=417187 --- Comment #15 from Stefan Maksimovic --- We tested these changes a couple of days ago on a number of mips32/mips64 development boards and found no regressions present as of now. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 417187] [MIPS] Conditional branch problem since 'grail' changes
https://bugs.kde.org/show_bug.cgi?id=417187 --- Comment #17 from Stefan Maksimovic --- Created attachment 126749 --> https://bugs.kde.org/attachment.cgi?id=126749&action=edit handle branches in delay slots We've taken a second look at the possible scenarios you described and updated the current changes so as to cover the special cases which could have possibly caused disInstr_MIPS_WRK to go into an arbitrarily deep recursion. The result is that valgrind now mimics the behaviour of a program by emitting a SIGILL in cases where the program ran by itself also does. Tested it on a contrived example (by having consecutive branches in the delay slots of those above) and managed to get a matching behaviour between valgrind and a standalone run of the example. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 417187] [MIPS] Conditional branch problem since 'grail' changes
https://bugs.kde.org/show_bug.cgi?id=417187 --- Comment #19 from Stefan Maksimovic --- We'll land the changes if you don't mind. One question though, do you happen to know the exact date of the code freeze? In order for us to know by which date we need to commit the patches. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 410757] glibc wrapper discrepancy for preadv2/pwritev2 system calls across different versions
https://bugs.kde.org/show_bug.cgi?id=410757 Stefan Maksimovic changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #8 from Stefan Maksimovic --- No need to do anything else for this issue, it was an omission on my part for not closing it after Mark's commit. Marking it as resolved/fixed. -- You are receiving this mail because: You are watching all bug changes.
