[llvm-commits] [PATCH 9/10] Initial support for PowerPC64 MCJIT

Jim Grosbach grosbach at apple.com
Tue Sep 18 13:34:43 PDT 2012


On Sep 18, 2012, at 1:16 PM, Adhemerval Zanella wrote:

> On 09/18/2012 04:41 PM, Jim Grosbach wrote:
>> On Sep 18, 2012, at 12:28 PM, Adhemerval Zanella wrote:
>> 
>>> On 09/17/2012 06:58 PM, Jim Grosbach wrote:
>>>> Hello,
>>>> 
>>>> First off, this is awesome to see PPC getting MC-ified. Thank you for working on this!
>>>> 
>>>> I don't know PPC well enough to comment on the architecture specific aspects of this, but a few general comments inline below:
>>> Thanks for the comments Jim, considerations below.
>>> 
>>> 
>>>> Is StubAddr guaranteed to be 32-bit aligned? Typically not.
>>> Although it is not guaranteed to be 32-bit aligned, I believe the way both relocation
>>> and the stub creation are done is with the assumption higher level objects knows how
>>> to place the data and call the stub creation and relocation methods with correct memory 
>>> arguments. For instance, if it calls the stub creation with a non 32-bits aligned memory,
>>> should the method just align it and possible overwriting a valid previous instruction or
>>> just fail?
>> Thanks for the updates. Looking good.
>> 
>> To this specific point, It needs to perform the assignment a byte at a time so as to not potentially generate unaligned memory accesses.
>> 
>> Remember, the MCJIT's local memory is not conceptually the same as the memory where the code will be executed. Self-hosted environments may execute it directly, but that's an optimization for that environment. The MCJIT model is that all of the relocation resolution, etc, is performed in the compilation process and then the client application (with help from the memory manager) transfers the sections into the execution address space (which may be remote, and indeed a completely different architecture than the host). Consider, for example, remote debugging of an ARM target via an x86_64 host with LLDB. The expression evaluation uses the MCJIT on the host to compile for ARM, then transfers the code to the target for execution. For the large chunk for the stub, I suggest just having a local static array and memcpy()'ing it into place.
>> 
>> Short answer is that while the addresses will often end up aligned and things will work properly, there's no guarantee of such by the MCJIT and the code should not rely on uint8_t* being anything more than byte aligned.
> 
> I wasn't aware of this MCJIT utilization and it makes sense now. However my first approach was
> just following what other architectures did. Both ARM and MIPS stub creation, for instance, also
> do not take this in consideration and creates stub using uint32_t pointer accesses.

Yeah, there is unfortunately some current code which already violates the host/target relationship. I'm in the process of cleaning some of that up, partly because it sets a misleading example.

Anyways, thanks again for working on this for PPC. It's great to see all the progress there recently.

-Jim

> 
> 
>> 
>> The rest of the changes look good, with one additional minor style tweak left for case labels:
>> +  case ELF::R_PPC64_ADDR14 :
>> +    {
>> +      assert(((Value + Addend) & 3) == 0);
>> +      uint16_t *insn = ((uint16_t*)RelocAddr+1);
>> +      *insn = (*insn & 3) | ((Value + Addend) & 0xfffc);
>> +    } break;
>> 
>> The open brace should go on the same line as the 'case' label and the close brace should have the same indentation level as the 'case' label.
> 
> Fixed.
> 
> -- 
> Adhemerval Zanella Netto
>  Software Engineer
>  Linux Technology Center Brazil
>  Toolchain / GLIBC on Power Architecture
>  azanella at linux.vnet.ibm.com / azanella at br.ibm.com
>  +55 61 8642-9890
> 




More information about the llvm-commits mailing list