[lld] r329014 - Define TrapInst for ppc64.

Rui Ueyama via llvm-commits llvm-commits at lists.llvm.org
Mon Apr 2 15:19:32 PDT 2018


On second thought, I'm not sure if this is safe on big-endian hosts. We
have a 4 byte integer literal and write it to an output using memcpy.
Doesn't this fail on big-endian host?


On Mon, Apr 2, 2018 at 2:14 PM Rafael Espindola via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> Author: rafael
> Date: Mon Apr  2 14:11:13 2018
> New Revision: 329014
>
> URL: http://llvm.org/viewvc/llvm-project?rev=329014&view=rev
> Log:
> Define TrapInst for ppc64.
>
> This is nice for testing since it is the first TrapInst whose bytes
> are not all the same.
>
> Added:
>     lld/trunk/test/ELF/fill-trap-ppc.s
> Modified:
>     lld/trunk/ELF/Arch/PPC64.cpp
>
> Modified: lld/trunk/ELF/Arch/PPC64.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/lld/trunk/ELF/Arch/PPC64.cpp?rev=329014&r1=329013&r2=329014&view=diff
>
> ==============================================================================
> --- lld/trunk/ELF/Arch/PPC64.cpp (original)
> +++ lld/trunk/ELF/Arch/PPC64.cpp Mon Apr  2 14:11:13 2018
> @@ -93,6 +93,8 @@ PPC64::PPC64() {
>    // And because the lowest non-zero 256M boundary is 0x10000000, PPC64
> linkers
>    // use 0x10000000 as the starting address.
>    DefaultImageBase = 0x10000000;
> +
> +  TrapInstr = 0x7fe00008;
>  }
>
>  static uint32_t getEFlags(InputFile *File) {
>
> Added: lld/trunk/test/ELF/fill-trap-ppc.s
> URL:
> http://llvm.org/viewvc/llvm-project/lld/trunk/test/ELF/fill-trap-ppc.s?rev=329014&view=auto
>
> ==============================================================================
> --- lld/trunk/test/ELF/fill-trap-ppc.s (added)
> +++ lld/trunk/test/ELF/fill-trap-ppc.s Mon Apr  2 14:11:13 2018
> @@ -0,0 +1,30 @@
> +# REQUIRES: ppc
> +
> +# RUN: llvm-mc -filetype=obj -triple=powerpc64le-linux %s -o %t.o
> +# RUN: ld.lld %t.o -o %t.ppc64le
> +# RUN: llvm-readobj -program-headers %t.ppc64le | FileCheck %s
> +# RUN: od -Ax -t x4 -N16 -j0x10ff0 %t.ppc64le | FileCheck %s
> -check-prefix=FILL
> +
> +# RUN: llvm-mc -filetype=obj -triple=powerpc64-linux %s -o %t.o
> +# RUN: ld.lld %t.o -o %t.ppc64
> +# RUN: llvm-readobj -program-headers %t.ppc64 | FileCheck %s
> +# RUN: od -Ax -t x4 -N16 -j0x10ff0 %t.ppc64 | FileCheck %s
> -check-prefix=FILL
> +
> +# CHECK: ProgramHeader {
> +# CHECK:   Type: PT_LOAD
> +# CHECK:        Offset: 0x10000{{$}}
> +# CHECK-NEXT:   VirtualAddress:
> +# CHECK-NEXT:   PhysicalAddress:
> +# CHECK-NEXT:   FileSize: 4096
> +# CHECK-NEXT:   MemSize:
> +# CHECK-NEXT:   Flags [
> +# CHECK-NEXT:     PF_R
> +# CHECK-NEXT:     PF_X
> +# CHECK-NEXT:   ]
> +
> +## Check that executable page is filled with traps at its end.
> +# FILL: 010ff0 7fe00008 7fe00008 7fe00008 7fe00008
> +
> +.globl _start
> +_start:
> +  nop
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20180402/12780d04/attachment.html>


More information about the llvm-commits mailing list