[valgrind] [Bug 399584] Support macOS Mojave (10.14)
https://bugs.kde.org/show_bug.cgi?id=399584 --- Comment #33 from Louis Brunner --- Jay, i.am.qix, I have merged a patch in my repository which should fix that issue. I didn't realize GitHub issues were disabled, feel free to reopen https://github.com/LouisBrunner/valgrind-macos/issues/3 in case you have any further problems. Regards, -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 416436] Unrecognised instruction at address 0x1006037BD (__pthread_init.cold.2) macOS 10.15
https://bugs.kde.org/show_bug.cgi?id=416436 --- Comment #2 from Louis Brunner --- Created attachment 125843 --> https://bugs.kde.org/attachment.cgi?id=125843=edit Fix _pthread_init illegal instruction by providing ptr_munge I have been investigating the problem and I have a fix (patch included). Some context: it is difficult to be sure without the libpthread sources for 10.15, but if you check libpthread-330.250.2 (for 10.14), you will find a parse_ptr_munge_params function that tries to get ptr_munge value from the environment (through the Apple environment or an actual environment variable, PTHREAD_PTR_MUNGE_TOKEN). In previous versions, __pthread_init would just carry on even if the value wasn't defined, but while stepping through the code, I have found that macOS 10.15 seems to crash using the ud2 instruction just after the environment variable check, hinting that this value is now required. My patch adds PTHREAD_PTR_MUNGE_TOKEN with a value of 1 everytime valgrind starts a program. Note that a value of 0 is considered an error by pthread. Disclaimer: while I found where ptr_munge is generated (kernel) and used (some kind of conversion in jmp instructions in libplatform), I don't understand what it does exactly. On the other hand, the dummy value doesn't seem to make a difference when executing a program with valgrind. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 416436] Unrecognised instruction at address 0x1006037BD (__pthread_init.cold.2) macOS 10.15
https://bugs.kde.org/show_bug.cgi?id=416436 Louis Brunner changed: What|Removed |Added CC||louis.brunner...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 399584] Support macOS Mojave (10.14)
https://bugs.kde.org/show_bug.cgi?id=399584 --- Comment #30 from Louis Brunner --- (In reply to Jay from comment #29) > Hi Rhys, > > Is there a way to install your patched version of Valgrind using a package > manager such as brew? I saw something similar with Louis Brunner (added > below), but was wondering if I could do the same with yours since it looks > like you and James have made a fair bit of progress towards stability. I'm > on 10.14.6 and have been waiting some time to be able to download Valgrind > for Mojave through homebrew, but I'm not sure if that's coming anytime soon. > > brew install --HEAD > https://raw.githubusercontent.com/LouisBrunner/valgrind-macos/master/ > valgrind.rb > > Also, thank you for your work on keeping Valgrind compatible with macOS. > Your work is seriously under-appreciated. > > Best, > Jay Hi Jay, I have updated my repository to support macOS 10.14.6, you can try it out with the same command: brew install --HEAD https://raw.githubusercontent.com/LouisBrunner/valgrind-macos/master/valgrind.rb Feel free to raise any issue you encounter. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 399584] Support macOS Mojave (10.14)
https://bugs.kde.org/show_bug.cgi?id=399584 --- Comment #16 from Louis Brunner --- Jake, Just apply the changes from every commit (https://github.com/LouisBrunner/valgrind-macos/commits/master) from the one made by Rhys (15d7631e71300670f6870307631447317d542e1a) to the penultimate (1caa52605dce5241bd9072b61b347b25adaea0a1). -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 399584] Support macOS Mojave (10.14)
https://bugs.kde.org/show_bug.cgi?id=399584 --- Comment #14 from Louis Brunner --- Rhys, I have been working on a series of patches based on your GitHub repository that allow Valgrind to work on macOS Mojave (albeit fairly experimentally). The following are included: - Empty stub for `mach_msg_destroy` which is required by the new mig - A bunch of suppressions for dyld related functions (which are probably way too generic) - `openat` support - `thread_get_special_reply_port` support - Output/check improvements for a handful of syscalls - Multi-threading support (signals are still buggy) I also added a README.md containing the result of `make regtest` for reference. The code is available here: https://github.com/LouisBrunner/valgrind-macos -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 399584] Support macOS Mojave (10.14)
https://bugs.kde.org/show_bug.cgi?id=399584 Louis Brunner changed: What|Removed |Added CC||louis.brunner...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 380269] [PATCH] No multithreading in macOS Sierra (10.12)
https://bugs.kde.org/show_bug.cgi?id=380269 --- Comment #9 from Louis Brunner --- Rhys: Doesn't ring a bell. I mainly had issues with mcwatchpoints, pselect_alarm and pth_term_signal. Is there anything I can do to help out? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 380269] [PATCH] No multithreading in macOS Sierra (10.12)
https://bugs.kde.org/show_bug.cgi?id=380269 --- Comment #7 from Louis Brunner <louis.brunner...@gmail.com> --- Created attachment 109548 --> https://bugs.kde.org/attachment.cgi?id=109548=edit Partial wqthread fix As reported by Alexandru in https://bugs.kde.org/show_bug.cgi?id=383723 and this thread, as well as by FX in https://bugs.kde.org/show_bug.cgi?id=385279, my previous patch doesn't include any fix for wqthread. Here is a new patch that can be applied on top of my previous and Alexandru's kevent_qos patches (which are needed for wqthread programs). It includes the following elements (which I didn't know how to breakdown between the different bug reports): - GS_CONST fix (as for regular threads) - Zero offset for tst->os_state.pthread (as it was the case for 10.6) - workq_ops(THREAD_KEVENT_RETURN) now behaves like workq_ops(THREAD_RETURN) - kevent_id (syscall:375) and thread_get_special_reply_port (mach:50) implementation (the kevent_id one is copied from Alexandru's kevent_qos) Note that after all these changes, programs using wqthreads still don't work. Unfortunately, I am running into race conditions with the BigLock: either one thread waiting for the lock to be released or another locking it twice. All these changes are wrapped in #if DARWIN_VERS >= DARWIN_10_13, apart from the THREAD_KEVENT_RETURN change. Last but not least, the patch doesn't worsen the regtest results: == 655 tests, 321 stderr failures, 74 stdout failures, 8 stderrB failures, 8 stdoutB failures, 31 post failures == -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 380269] [PATCH] No multithreading in macOS Sierra (10.12)
https://bugs.kde.org/show_bug.cgi?id=380269 --- Comment #6 from Louis Brunner <louis.brunner...@gmail.com> --- Rhys, No problem, here are the results before the patch (but with https://bugs.kde.org/show_bug.cgi?id=385279 applied): == 655 tests, 335 stderr failures, 85 stdout failures, 8 stderrB failures, 8 stdoutB failures, 31 post failures == And after: == 655 tests, 322 stderr failures, 74 stdout failures, 8 stderrB failures, 8 stdoutB failures, 31 post failures == Note that some tests block the test runner in both case (mcwatchpoints) and some tests block after the patch (pselect_alarm and pth_term_signal). This is due to the tests previously crashing because of pthread, and now some issues with signals is preventing them to complete. Here is the difference between the failures: $ diff tests_pre.txt tests_post.txt 49,50d48 < memcheck/tests/err_disable3 (stderr) < memcheck/tests/err_disable4 (stderr) 99d96 < memcheck/tests/threadname(stderr) 150,151d146 < callgrind/tests/threads-use (stderr) < callgrind/tests/threads (stderr) 210,216d204 < none/tests/pselect_alarm (stderr) < none/tests/pth_2sig (stderr) < none/tests/pth_atfork1 (stdout) < none/tests/pth_atfork1 (stderr) < none/tests/pth_blockedsig(stdout) < none/tests/pth_blockedsig(stderr) < none/tests/pth_cancel1 (stdout) 219,221d206 < none/tests/pth_cvsimple (stdout) < none/tests/pth_cvsimple (stderr) < none/tests/pth_exit (stderr) 224,225d208 < none/tests/pth_stackalign(stdout) < none/tests/pth_stackalign(stderr) 229d211 < none/tests/sigsusp (stderr) 234d215 < none/tests/threaded-fork (stdout) 330d310 < helgrind/tests/pth_destroy_cond (stdout) 342d321 < helgrind/tests/tc07_hbl1 (stdout) 344d322 < helgrind/tests/tc08_hbl2 (stdout) 348d325 < helgrind/tests/tc11_XCHG (stdout) 358d334 < helgrind/tests/tc21_pthonce (stdout) -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 380269] No multithreading in macOS Sierra (10.12)
https://bugs.kde.org/show_bug.cgi?id=380269
--- Comment #4 from Louis Brunner <louis.brunner...@gmail.com> ---
Created attachment 109303
--> https://bugs.kde.org/attachment.cgi?id=109303=edit
Fix crash when using multithreading on Mac OS X >= 10.12
I have finally managed to fix the issue that made pthread SIGSEGV when starting
a new thread.
The issue was related to the TSD. In _pthread_body, an inline function called
__pthread_add_thread is called, which locks a mutex using a os_unfair_lock_lock
function from libplatform. These functions use the TSD while calling
_os_lock_owner_get_self to retrieve the current the current MAC Thread using
_os_tsd_get_direct(__TSD_MACH_THREAD_SELF). Looking at this last function will
reveal a `__asm__("mov %%gs:%1, %0" : "=r" (ret) : "m" (*(void **)(slot *
sizeof(void *;`, knowing that __TSD_MACH_THREAD_SELF is 3, that outputs the
`mov %gs:0x18,%ecx` that was causing problems.
Now, I don't know why GS_CONST is suddenly 0 instead of the TSD address, but I
found that pthread keeps the latter in its pthread_t structure and that it
conveniently gives us the offset in an internal structure passed to
bsdthread_register by _pthread_bsdthread_init (4th argument). In
syswrap-darwin.c, we already store a few arguments passed to
bsdthread_register, so I added a new one, which is the offset of the TSD member
in the pthread_t structure. While starting the new thread in pthread_hijack, we
can then set the value of GS_CONST to self (current pthread_t address) +
pthread_tsd_offset.
The program then executes normally when using pthread and multithreading. Note
that a lot of programs (including yours Alexandru) still crash or malfunction
(mismanagement of signals, ...) once they start running. However these issues
seem unrelated to this particular pthread problem.
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 385279] unhandled syscall: mach:43 (mach_generate_activity_id)
https://bugs.kde.org/show_bug.cgi?id=385279 --- Comment #3 from Louis Brunner <louis.brunner...@gmail.com> --- Created attachment 109108 --> https://bugs.kde.org/attachment.cgi?id=109108=edit Handle mach_generate_activity_id for Mac OS >= 10.12 Hi Rhys, This patch adds mach_generate_activity_id for Mac OS >= 10.12 in valgrind, which allows it to run on High Sierra (10.13). -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 383811] Support macOS High Sierra (10.13)
https://bugs.kde.org/show_bug.cgi?id=383811 Louis Brunner <louis.brunner...@gmail.com> changed: What|Removed |Added CC||louis.brunner...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 385279] unhandled syscall: mach:43 (mach_generate_activity_id)
https://bugs.kde.org/show_bug.cgi?id=385279 Louis Brunner <louis.brunner...@gmail.com> changed: What|Removed |Added CC||louis.brunner...@gmail.com -- 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 Louis Brunner <louis.brunner...@gmail.com> changed: What|Removed |Added Depends on||380269 Referenced Bugs: https://bugs.kde.org/show_bug.cgi?id=380269 [Bug 380269] No multithreading in macOS Sierra (10.12) -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 380269] No multithreading in macOS Sierra (10.12)
https://bugs.kde.org/show_bug.cgi?id=380269 Louis Brunner <louis.brunner...@gmail.com> changed: What|Removed |Added Blocks||365327 CC||louis.brunner...@gmail.com Referenced Bugs: https://bugs.kde.org/show_bug.cgi?id=365327 [Bug 365327] Support macOS Sierra (10.12) -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 380269] New: No multithreading in macOS Sierra (10.12)
https://bugs.kde.org/show_bug.cgi?id=380269 Bug ID: 380269 Summary: No multithreading in macOS Sierra (10.12) Product: valgrind Version: 3.12 SVN Platform: Mac OS X Disk Images OS: OS X Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: jsew...@acm.org Reporter: louis.brunner...@gmail.com Target Milestone: --- On macOS Sierra (10.12), if pthread_create is called while using valgrind the program stops because of a SIGSEGV. Snippet of the error: ==22190== Thread 2: ==22190== Invalid read of size 4 ==22190==at 0x10050790D: _pthread_body (in /usr/lib/system/libsystem_pthread.dylib) ==22190==by 0x1005078FA: _pthread_start (in /usr/lib/system/libsystem_pthread.dylib) ==22190==by 0x100507100: thread_start (in /usr/lib/system/libsystem_pthread.dylib) ==22190== Address 0x18 is not stack'd, malloc'd or (recently) free'd After some investigation, this bug comes when starting the new thread just before the routine supplied to pthread_create is called. From my limited understanding of assembly/macOS internals/valgrind, the thread tries to access its thread-local storage (TLS) and fails because gs (the register that seems to be allowed to it on macOS) is 0. This means that valgrind interpret the problematic instruction mov %gs:0x18,%ecx as lea [0+0x18],%ecx While debbuging with gdb and lldb, with and without valgrind, I noted that gs is always 0. So I don't know if it's technically possible but macOS Sierra seems to hide the value of gs from the user, so when the binary is run without valgrind the instruction loads the correct address even though gs is 0. When running with valgrind, gs is taken directly from the register and is always 0 which triggers the bug. The only solution I can see is guessing the address of the TLS and set it as gs' value before going into pthread (in pthread_hijack), e.g. diff --git a/coregrind/m_syswrap/syswrap-amd64-darwin.c b/coregrind/m_syswrap/syswrap-amd64-darwin.c index c827bab..3c926cf 100644 --- a/coregrind/m_syswrap/syswrap-amd64-darwin.c +++ b/coregrind/m_syswrap/syswrap-amd64-darwin.c @@ -364,6 +364,10 @@ void pthread_hijack(Addr self, Addr kport, Addr func, Addr func_arg, vex->guest_R9 = flags; vex->guest_RSP = sp; +#if DARWIN_VERS >= DARWIN_10_12 + vex->guest_GS_CONST = self; +#endif + // Record thread's stack and Mach port and pthread struct tst->os_state.pthread = self; tst->os_state.lwpid = kport; However, I wasn't able to guess a correct value for gs, and with the above fix the program goes on but fails at the next pthread call, example with the above fix applied: ==23490== Thread 2: ==23490== Invalid read of size 4 ==23490==at 0x100508538: _pthread_testcancel (in /usr/lib/system/libsystem_pthread.dylib) ==23490==by 0x1002E0AD4: nanosleep (in /usr/lib/system/libsystem_c.dylib) ==23490==by 0x1002E09D2: sleep (in /usr/lib/system/libsystem_c.dylib) ==23490==by 0x10E02: slavethread (pth_term_signal.c:27) ==23490==by 0x1005079AE: _pthread_body (in /usr/lib/system/libsystem_pthread.dylib) ==23490==by 0x1005078FA: _pthread_start (in /usr/lib/system/libsystem_pthread.dylib) ==23490==by 0x100507100: thread_start (in /usr/lib/system/libsystem_pthread.dylib) ==23490== Address 0x54485258 is not stack'd, malloc'd or (recently) free'd Note that at this point, gdb shows gs value as 0x4ee4000 instead of 0x74ee4000, so maybe the value is getting truncated at some point. In previous versions of macOS, valgrind would set guest_GS_CONST in the thread_fast_set_cthread_self (syswrap-darwin.c:9133) trap. However this function is not called before going into the new thread, leaving an invalid value for gs. -- 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 Louis Brunner <louis.brunner...@gmail.com> changed: What|Removed |Added Attachment #105473|0 |1 is obsolete|| --- Comment #2 from Louis Brunner <louis.brunner...@gmail.com> --- Created attachment 105563 --> https://bugs.kde.org/attachment.cgi?id=105563=edit Adds the pselect handler (Darwin specific) Ivo, My bad, thanks for the correction! I moved it to Darwin instead of generic. -- 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 #26 from Louis Brunner <louis.brunner...@gmail.com> --- Created attachment 105483 --> https://bugs.kde.org/attachment.cgi?id=105483=edit Checks in new syscalls/traps Rhys, I created new issue for pselect and ulock_wait (couldn't find the failing test though). Could we simply disable pth_term_signal (the pthread test that hang) while we search for a fix? It makes testing pretty cumbersome. Do you have any idea what the problem could be? Maybe linked to another pthread problem (like 349128)? I have also included a patch based on the one for ulock_wait (379754) which includes more checks for the newly added syscalls/traps. Do you want me to create an issue per syscall? -- 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 Louis Brunner <louis.brunner...@gmail.com> changed: What|Removed |Added Depends on||379754 Referenced Bugs: https://bugs.kde.org/show_bug.cgi?id=379754 [Bug 379754] Missing syscall ulock_wait (OS X 10.12) -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 379754] Missing syscall ulock_wait (OS X 10.12)
https://bugs.kde.org/show_bug.cgi?id=379754 Louis Brunner <louis.brunner...@gmail.com> changed: What|Removed |Added Blocks||365327 Referenced Bugs: https://bugs.kde.org/show_bug.cgi?id=365327 [Bug 365327] Support macOS Sierra (10.12) -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 379748] Missing pselect syscall (OS X 10.12)
https://bugs.kde.org/show_bug.cgi?id=379748 Louis Brunner <louis.brunner...@gmail.com> changed: What|Removed |Added CC||louis.brunner...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 379754] Missing syscall ulock_wait (OS X 10.12)
https://bugs.kde.org/show_bug.cgi?id=379754 Louis Brunner <louis.brunner...@gmail.com> changed: What|Removed |Added CC||louis.brunner...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 379754] New: Missing syscall ulock_wait (OS X 10.12)
https://bugs.kde.org/show_bug.cgi?id=379754 Bug ID: 379754 Summary: Missing syscall ulock_wait (OS X 10.12) Product: valgrind Version: 3.13 SVN Platform: Mac OS X Disk Images OS: OS X Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: jsew...@acm.org Reporter: louis.brunner...@gmail.com Target Milestone: --- Created attachment 105482 --> https://bugs.kde.org/attachment.cgi?id=105482=edit Adds the ulock_wait syscall Add a missing syscall in OS X 10.12: ulock_wait. This patch also adds some code that can be reused by ulock_wake. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 379748] Missing pselect syscall (OS X 10.12)
https://bugs.kde.org/show_bug.cgi?id=379748 Louis Brunner <louis.brunner...@gmail.com> changed: What|Removed |Added Summary|Missing pselect syscall |Missing pselect syscall (OS ||X 10.12) -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 379748] Missing pselect syscall
https://bugs.kde.org/show_bug.cgi?id=379748 Louis Brunner <louis.brunner...@gmail.com> changed: What|Removed |Added Blocks||365327 Referenced Bugs: https://bugs.kde.org/show_bug.cgi?id=365327 [Bug 365327] Support macOS Sierra (10.12) -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 379748] New: Missing pselect syscall
https://bugs.kde.org/show_bug.cgi?id=379748 Bug ID: 379748 Summary: Missing pselect syscall Product: valgrind Version: 3.13 SVN Platform: Mac OS X Disk Images OS: OS X Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: jsew...@acm.org Reporter: louis.brunner...@gmail.com Target Milestone: --- Created attachment 105473 --> https://bugs.kde.org/attachment.cgi?id=105473=edit Adds the pselect handler Adds the pselect handler in the generic syscall file because it is defined by POSIX and the implementation is fairly basic (select with an extra check). It is only included by Darwin (Linux seems to have its own handler). -- 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 Louis Brunner <louis.brunner...@gmail.com> changed: What|Removed |Added Depends on||379748 Referenced Bugs: https://bugs.kde.org/show_bug.cgi?id=379748 [Bug 379748] Missing pselect syscall -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 379373] Syscall param msg->desc.port.name points to uninitialised byte(s) on macOS 10.12
https://bugs.kde.org/show_bug.cgi?id=379373 --- Comment #1 from Louis Brunner <louis.brunner...@gmail.com> --- Created attachment 105470 --> https://bugs.kde.org/attachment.cgi?id=105470=edit Define the kernelrpc_mach_port_construct_trap mach trap The problem seems to be caused by a call to task_set_special_port with a port constructed with mach_port_construct (handled by kernelrpc_mach_port_construct_trap). The attached patch resolves the issue by implementing the checks in the PRE/POST of this trap. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 349128] Access not within mapped region in _pthread_find_thread (OS X 10.11)
https://bugs.kde.org/show_bug.cgi?id=349128 Louis Brunner <louis.brunner...@gmail.com> changed: What|Removed |Added CC||louis.brunner...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 379373] Syscall param msg->desc.port.name points to uninitialised byte(s) on macOS 10.12
https://bugs.kde.org/show_bug.cgi?id=379373 Louis Brunner <louis.brunner...@gmail.com> changed: What|Removed |Added CC||louis.brunner...@gmail.com -- 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 #24 from Louis Brunner <louis.brunner...@gmail.com> --- Hi Rhys, Thank you for the merge! While making the changes for the new dylib loading, I encountered a crash coming from is_in_syscall. I blamed it on the experimental nature of my patch at the time and I can't remember what triggered the crash. You mentioned that you had older macOS VMs, do you have any advice/guide of any sort to help me set one up for testing? I could look into the failing test and the warnings linked to `getentropy` and `ulock_wake` (if you didn't fix them already). I was also working on a new version that included a pselect syscall wrapper (found it missing while testing python with valgrind), I will add it later. -- 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 Louis Brunner <louis.brunner...@gmail.com> changed: What|Removed |Added Attachment #104964|0 |1 is obsolete|| --- Comment #16 from Louis Brunner <louis.brunner...@gmail.com> --- Created attachment 105218 --> https://bugs.kde.org/attachment.cgi?id=105218=edit macOS Sierra incomplete support v2 Thank you for the feedback! Austin, I just added a new patch that solves this issue (I can't believe that I didn't check that...). Thanks for the check on 10.11! Julian, I don't have access to any 10.10 or 10.11, but I am trying to install one in a VM right now. Technically, most of the changes are scoped in the proper `#if DARWIN_VERS >= DARWIN_10_XX`. -- 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 Louis Brunner <louis.brunner...@gmail.com> changed: What|Removed |Added CC||louis.brunner...@gmail.com --- Comment #12 from Louis Brunner <louis.brunner...@gmail.com> --- Created attachment 104964 --> https://bugs.kde.org/attachment.cgi?id=104964=edit macOS Sierra incomplete support I have been working on a patch to support macOS Sierra. At the moment, it works for a variety of programs (python, GIMP, most basic commands like ls, mkdir) but it is still incomplete (warnings in dyld, libsystem_kernel... crash for some GUI programs). The patch adds a few required syscalls with placeholder implementations (faccessat, fstatat64, csrctl, getentropy and ulock_wake) and the new way of loading dylib (placing them at the end of the currently loaded segments). The second change means we need to know where the last segment was loaded, which means carrying around one more pointer on pointer in every function (which already have 6-9 arguments), that's why I created a structure (load_info_t) to store all this information and easily carry it around. It also adds one assert in is_in_syscall in coregrind/m_syswrap/syswrap-main.c to match the other syscall related functions in the same file. I had a difficult to diagnose crash in this function because it didn't check for the existence of the syscall table. Tell me if you need any change -- You are receiving this mail because: You are watching all bug changes.
