[llvm-commits] [llvm] r57846 - in /llvm/trunk: include/llvm/System/Memory.h lib/System/Unix/Memory.inc lib/System/Win32/Memory.inc lib/Target/ARM/ARMJITInfo.cpp

[Evan Cheng]

On Oct 21, 2008, at 9:36 AM, Jim Grosbach wrote:

>
> On Oct 21, 2008, at 9:24 AM, Evan Cheng wrote:
>>>> Is this code Mac OS X specific? Is "push" accepted by all the
>>>> assemblers?
>>>>
>>>
>>> It's standard, but relatively recent (sometime in the last few  
>>> years,
>>> depending on toolchain) for the mnemonic to be recognized in ARM
>>> state. How concerned are we about older assemblers?
>>
>> I think we should use mnemonic that are as widely accepted as
>> possible. I believe the original author did test the callback routine
>> on his target. We should be careful not to break it.
>>
>
> Sounds good. I'll tweak it this morning.

Thanks.

>
>
>> Having the stub making a system
>> call to change memory privilege just seem icky to me. My basic idea  
>> is
>> to allocate a chunk RX memory for code (like what's being done now)
>> and a chunk of RW memory for data and anything that's going to be
>> changed during execution (i.e. putting addresses of lazily compiled
>> functions there). This will require a larger scale rewrite so it's  
>> not
>> something that should be planned for the near future.
>>
>
> No disagreement here. I played with that for a while, but it gets
> pretty hairy, especially with lazy compilation. I backed off and chose
> to get it working first, even with the ugly syscalls. Not that in re-
> writing the stub we're writing not just an address, but an
> instruction, for example. The meta-data for the memory blocks are
> another tricky spot.

This can be simplified if codegen always generate indirect calls and  
the addresses are always loaded from the RW region. We can populate  
them with the address of the callback routine first and update them as  
lazy compilation happens.

>
>
> Doing something about this stuff would require a new, or at least
> significantly re-worked, JIT Memory Manager, possibly one that's
> target specific. As you say, a pretty significant refactoring and
> probably outside the scope of what we want to look at right now.

Yep. Not something we want to deal with right now.

Evan

>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits