[llvm-bugs] [Bug 26519] New: Clang 3.8.0's "Target: powerpc-unknown-freebsd11.0" code generation is violating the ABI involved

[via llvm-bugs]

https://llvm.org/bugs/show_bug.cgi?id=26519

            Bug ID: 26519
           Summary: Clang 3.8.0's "Target: powerpc-unknown-freebsd11.0"
                    code generation is violating the ABI involved
           Product: clang
           Version: 3.8
          Hardware: Other
                OS: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: markmi at dsl-only.net
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

Comparing clang 3.8.0 (via FreeBSD's projects/clang380-import svn) generated
code for TARGET_ARCH=powerpc (32-bit) to gcc 4.2.1 generated code. . .

clang 3.8.0 based Str_Match preamble (from make):

0x181a4a8 <Str_Match>:    mflr    r0
0x181a4ac <Str_Match+4>:    stw     r31,-4(r1) # Clang's frame pointer (r31) 
                                                   # saved before stack pointer
changed.
0x181a4b0 <Str_Match+8>:    stw     r0,4(r1)   # lr saved before stack pointer
changed.
0x181a4b4 <Str_Match+12>:    stwu    r1,-32(r1) # Stack pointer finally saved
and
                                                   # changed.
0x181a4b8 <Str_Match+16>:    mr      r31,r1     # r31 is the frame pointer
under clang.
0x181a4bc <Str_Match+20>:    stw     r30,24(r31)

gcc 4.2.1 based Str_Match preamble:

0x1819cb8 <Str_Match>:    mflr    r0
0x1819cbc <Str_Match+4>:    stwu    r1,-32(r1) # Stack pointer saved and
changed first.
0x1819cc0 <Str_Match+8>:    stw     r31,28(r1) # r31 saved after stack pointer
changed.
0x1819cc4 <Str_Match+12>:    mr      r31,r3     # gcc 4.2.1 does not reserve
                                                   # r31 for use as a frame
pointer.
0x1819cc8 <Str_Match+16>:    stw     r30,24(r1)
0x1819ccc <Str_Match+20>:    stw     r0,36(r1)  # lr saved after stack pointer
changed.

Picking a different example for postamble code, showing just clang 3.8.0's
code:

0x1801b8c <Buf_AddBytes+104>:    lwz     r30,24(r31)
0x1801b90 <Buf_AddBytes+108>:    lwz     r29,20(r31)
0x1801b94 <Buf_AddBytes+112>:    lwz     r28,16(r31)
0x1801b98 <Buf_AddBytes+116>:    lwz     r27,12(r31)
0x1801b9c <Buf_AddBytes+120>:    lwz     r26,8(r31)
0x1801ba0 <Buf_AddBytes+124>:    addi    r1,r1,32   # Stack pointer adjusted
first
0x1801ba4 <Buf_AddBytes+128>:    lwz     r0,4(r1)
0x1801ba8 <Buf_AddBytes+132>:    lwz     r31,-4(r1) # Then Frame Pointer load
happens
                                                   # "outside" the new stack
range.
0x1801bac <Buf_AddBytes+136>:    mtlr    r0
0x1801bb0 <Buf_AddBytes+140>:    blr

In other words: clang 3.8.0's generated 32-bit powerpc code is based on there
being a safe scratch area below the stack ("below" by memory address). So
similar to the 224 byte "red zone" area that 32-bit AIX powerpc and 32-bit
Darwin powerpc use.


I'm told by Nathan Whithorn that "the 32-bit ELF ABI does not require any such
red zone" and so that clang 3.8.0 is violating the ABI that is supposed to be
involved.

I do not have specific document or section references (or web links) to list
for the ABI details at this time. I'm just reporting what I'm told by FreeBSD
folks.


I used "make" code as the example above because something like "make -j 6
buildworld" uses signal delivery extensively (SIGCHLD) and such a build its
gets a SEGV in a make process within the 1st few minutes (on a "Quad core G5
PowerMac" using a FreeBSD powerpc 32-bit installation). The signal delivery is
sometimes replacing the value at "-4(r1)" in the above code before it is loaded
back into r31 (the clang 3.8.0 framepointer register for powerpc as it is
currently generating code). The FreeBSD signal delivery for 32-bit powerpc does
not have/use a "red zone" on the smaller-address side of the stack.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20160207/4be32977/attachment.html>