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: unassignedclangb...@nondot.org
Reporter: mar...@dsl-only.net
CC: llvm-bugs@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.
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
