similar to: [5.0.0 Release] Please help fix the remaining blockers (2 days left!)

Hi, Can anyone tell me something about mmap and vm_protect on ARM+Apple systems? I'm working on a new memory manager implementation for MCJIT and I want to replace calls to Memory::AllocateRWX with calls to Memory::allocateMappedMemory, possibly still with the RWX flags. However, looking at the Memory::AllocateRWX implementation I see that it's jumping through some hoops in the case

Hi Andy, On Nov 16, 2012, at 1:56 PM, "Kaylor, Andrew" <andrew.kaylor at intel.com> wrote: > Hi, > > Can anyone tell me something about mmap and vm_protect on ARM+Apple systems? Some. :) > > I’m working on a new memory manager implementation for MCJIT and I want to replace calls to Memory::AllocateRWX with calls to Memory::allocateMappedMemory, possibly still

"ARM Darwin can't do this. Memory is never allowed to be both writable and executable at the same time." That seems very sensible. So do the JIT engines just not work there now? Currently both MCJIT and JIT are using AllocateRWX which on that platform mmap's the memory as RX, then vm_protect's it as RX+VM_PROT_COPY, then vm_protect's it as RW. My best guess is that

Hello everyone A previous thread about OrcJIT brought up bug reports on Bugzilla. A quick search gives 20+ results: https://bugs.llvm.org/buglist.cgi?component=OrcJIT&list_id=162232&query_format=advanced&resolution=--- While some of them are obviously outdated (addModuleSet API cleanup [1]), others may actually be relevant again (Small code model? [2]). If you reported one of them,

I'd be interested in the existence of a high-quality, open-source, portable linker for apple platforms, but not enough to help make that happen. If I _was_ gonna work on something related to that, I'd probably be inclined to instead add any required features to allow an ELF linker to target a notional darwin-elf target, and to have clang emit darwin-elf object files, and then write a

Hello all, I'm trying to better understand the state of Mach-O support in lld. The lld docs state that "the linker supports ELF (Unix), PE/COFF (Windows), Mach-O (macOS) and WebAssembly in descending order of completeness." [1] True to that statement, I found an email on this list from Jan 2018 stating that "MachO support in lld is not really ready for real world usage. It was

Hi, three years ago Cortado found its new home xiph.org (as per http://lists.xiph.org/pipermail/theora/2009-October/002976.html ). However there are still 13 open bug reports in Wikimedia Bugzilla: https://bugzilla.wikimedia.org/buglist.cgi?query_format=advanced&resolution=---&product=Cortado Would you like me to upstream these tickets to

Hi Stefan Thank you! In case, you missed in llvm-dev listing: you can find the proposal here : link. <https://docs.google.com/document/d/1202EcXlWMQ8yxu5qD0b5fE0a_kihlcaPNpZo_Jk0YeQ/edit?usp=sharing> Thanks for working on summarising the Bugzilla tickets to track the recent changes in ORC this is really helpful. On Sat, 18 May 2019 at 21:33, Stefan Gränitz <stefan.graenitz at

Hello everyone, I want to contribute to LLVM. Previously I had written little compilers for which I used LLVM as the backend. How can I get started? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170826/fe62fa9f/attachment.html>

On 17 Nov 2012, at 00:12, Kaylor, Andrew wrote: > My best guess is that this is trying to set up something that’s actually backed by two pages where whatever is written to the RW page will be copied to the RX page, though if that’s possible it would seem to defeat the purpose of not allowing RWX. The correct way of implementing this is to have one physical page mapped to two locations in

On Thu, Jun 11, 2009 at 12:54 PM, Evan Cheng<evan.cheng at apple.com> wrote: > > > > On Jun 10, 2009, at 12:17 PM, Jeffrey Yasskin wrote: > >> In X86CodeGen.cpp, the following code appears in the handler used for >> CALL64pcrel32 instructions: >> >>       // Assume undefined functions may be outside the Small codespace. >>       bool NeedStub =

On Jun 10, 2009, at 12:17 PM, Jeffrey Yasskin wrote: > In X86CodeGen.cpp, the following code appears in the handler used for > CALL64pcrel32 instructions: > > // Assume undefined functions may be outside the Small > codespace. > bool NeedStub = > (Is64BitMode && > (TM.getCodeModel() == CodeModel::Large || >

In X86CodeGen.cpp, the following code appears in the handler used for CALL64pcrel32 instructions: // Assume undefined functions may be outside the Small codespace. bool NeedStub = (Is64BitMode && (TM.getCodeModel() == CodeModel::Large || TM.getSubtarget<X86Subtarget>().isTargetDarwin())) || Opcode == X86::TAILJMPd;

On Nov 16, 2012, at 4:12 PM, "Kaylor, Andrew" <andrew.kaylor at intel.com> wrote: > “ARM Darwin can't do this. Memory is never allowed to be both writable and executable at the same time.” > > That seems very sensible. So do the JIT engines just not work there now? They work by allocating RW memory, then switching the permissions to RX before running any code

Hi, Here are the list of patches that we are waiting on before tagging GA for Gluster 4.0. (packages and release announcement comes in about 2-5 days post this). We hope to be ready to tag the release on Monday 5th March, and will keep the list posted on a daily basis on any slips. 1) Patches waiting regression votes before merge: - https://review.gluster.org/#/c/19663/ -

LLVMers, The 2.4 release is blocked by PR2888. If anyone can help debug this problem, it would help us get the release out sooner. Thanks! -Tanya

> The 2.4 release is blocked by PR2888. If anyone can help debug this > problem, it would help us get the release out sooner. SPEC is not publicly available, is that right? Maybe it's possible to attach some reduced code to the PR so that people without SPEC can take a look. Ciao, Duncan.

On Mar 30, 2010, at 3:45 PM, David Greene wrote: > On Tuesday 30 March 2010 16:09:03 Tanya Lattner wrote: > >> Please take a look at all release blockers: >> http://llvm.org/bugs/show_bug.cgi?id=6586 > > 5893 is not release-critical according to Doug. > Will take care of this. > 6640 appears to be a test system problem with a patch available (one of the >

On Mar 30, 2010, at 4:04 PM, David Greene wrote: > On Tuesday 30 March 2010 17:45:16 David Greene wrote: >> On Tuesday 30 March 2010 16:09:03 Tanya Lattner wrote: >>> Please take a look at all release blockers: >>> http://llvm.org/bugs/show_bug.cgi?id=6586 >> >> 5893 is not release-critical according to Doug. >> >> 6640 appears to be a test

Top of the morning all... So I reworked the pseudo IDS/Brute Force Asterisk script for those who want to either use it, or use it as a baseline to build a better one... The script now does a few things... It logs those with password issues, and blocks them as well. This was done to ensure that a remote user who was blocked can be found in the log. E.g., Sally the homemaker keeps fiddling