[PPC64] Add test for toc-restore on recursive call.

[sfertile]

Summary

A test verifying that toc restores are properly inserted following recursive calls, as well as briefly describing why they are needed.

Prompted by the discussion in https://reviews.llvm.org/D46204 related to older builds of libstdc++.

[MaskRay]

test/ELF/ppc64-toc-restore-recursive-call.s

42

Are these extra operations (addi, mulld, ...) needed to make the test feel more authentic?

45

Is this related to the behavior of powerpc gcc >= 5.0?

https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gold/powerpc.cc;hb=4e57b456393946cb4f90131b78e162cdec903c8a#l9069

We had a discussion in https://reviews.llvm.org/D46204 that pre-5 versions of GCC did not emit a nop after bl.

[sfertile]

test/ELF/ppc64-toc-restore-recursive-call.s

42

essentially. Its from one of the unit tests I wrote to figure out how we could have a recursive function call that crossed module boundaries, so I needed some 'testable' behavior.

45

Yes that discussion is what prompted this, this test is for documenting that we need the toc restore following the recursive call.

[MaskRay]

LG (but please wait for the code owner).

Just a random grumble not related to this test:

1. CHECK: 1003c: {{[0-9a-fA-F ]+}} bl .+67108804

We should really fix the address display in disassembler (it requires passing addresses in MC disassembler if I remember correctly)... (it makes llvm-objdump awkward to use while objdump provides a better display)

[ruiu]

LGTM

[MaskRay]

test/ELF/ppc64-toc-restore-recursive-call.s

42

And I asked about this because I found that ppc64 tests tend to be verbose while tests of other architectures usually only contain the construction that is relevant in question and very few set up.

The way other tests are organized make them outstanding what are being tested while I the verbosity has the merit that they feel more natural (the context may help understanding). I was just asking, not really have an opinion on what should be favored...

[sfertile]

test/ELF/ppc64-toc-restore-recursive-call.s

42

I appreciate the feedback. I definitely find the context helps my understanding , but can see how it obfuscates what exactly is being tested. I imagine that since I'm typically very familiar with the 'surrounding' extra code I probably tend to underestimate that effect as well :)

test/ELF/ppc64-toc-restore-recursive-call.s

+# REQUIRES: ppc
+
+# RUN: llvm-mc -filetype=obj -triple=powerpc64le-unknown-linux %s -o %t1.o
+# RUN: ld.lld -shared %t1.o -o %t
+# RUN: llvm-objdump -d -r %t | FileCheck %s
+
+# For a recursive call that is interposable the linker calls the plt-stub rather
+# then calling the function directly. Since the call is through a plt stub and
+# might be interposed with a different definition at runtime, a toc-restore is
+# required to follow the call.
+
+# The decision to use a plt-stub for the recursive call is not one I feel
+# strongly about either way. It was done because it matches what bfd and gold do
+# for recursive calls as well as keeps the logic for recursive calls consistent
+# with non-recursive calls.
+
+# CHECK-LABEL: __plt_recursive_func:
+# CHECK-NEXT: 10000:
+# CHECK-LABEL: recursive_func
+# CHECK-NEXT:  10014:
+# CHECK:       1003c: {{[0-9a-fA-F ]+}} bl .+67108804
+# CHECK-NEXT:  ld 2, 24(1)
+
+        .abiversion 2
+        .section ".text"
+        .p2align 2
+        .global recursive_func
+        .type recursive_func, @function
+recursive_func:
+.Lrf_gep:
+    addis 2, 12, .TOC.-.Lrf_gep@ha
+    addi  2, 2, .TOC.-.Lrf_gep@l
+    .localentry recursive_func, .-recursive_func
+    cmpldi 3, 2
+    blt   0, .Lend
+
+    mflr 0
+    std 0, 16(1)
+    stdu 1, -32(1)
+    addi 5, 3, -1
+    mulld 4, 4, 3
+    mr 3, 5
+    bl recursive_func
+    nop
+    mr 4, 3
+    addi 1, 1, 32
+    ld 0, 16(1)
+    mtlr 0
+
+.Lend:
+    extsw 3, 4
+    blr