[Bug 207325] projects/clang380-import for TARGET_ARCH=powerpc : c++ exceptions cause SEGV (9 line program); powerpc64 __builtin_dwarf_cfa() issue as well

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Sun Feb 28 00:20:27 UTC 2016


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207325

--- Comment #8 from Mark Millard <markmi at dsl-only.net> ---
(In reply to Mark Millard from comment #6)

# more builtin_dwarf_cfa.cpp 
extern void g(void*);
void f() { g(__builtin_dwarf_cfa()); }

In a TARGET_ARCH=powerpc64 context:

# clang++ -c -g -std=c++11 -Wall -pedantic builtin_dwarf_cfa.cpp
# /usr/local/bin/objdump -d --prefix-addresses builtin_dwarf_cfa.o

builtin_dwarf_cfa.o:     file format elf64-powerpc-freebsd


Disassembly of section .text:
0000000000000000 <._Z1fv> mflr    r0
0000000000000004 <._Z1fv+0x4> std     r31,-8(r1)
0000000000000008 <._Z1fv+0x8> std     r0,16(r1)
000000000000000c <._Z1fv+0xc> stdu    r1,-128(r1)
0000000000000010 <._Z1fv+0x10> mr      r31,r1
0000000000000014 <._Z1fv+0x14> mr      r3,r31
0000000000000018 <._Z1fv+0x18> bl      0000000000000018 <._Z1fv+0x18>
000000000000001c <._Z1fv+0x1c> nop
0000000000000020 <._Z1fv+0x20> addi    r1,r1,128
0000000000000024 <._Z1fv+0x24> ld      r0,16(r1)
0000000000000028 <._Z1fv+0x28> ld      r31,-8(r1)
000000000000002c <._Z1fv+0x2c> mtlr    r0
0000000000000030 <._Z1fv+0x30> blr
        ...

r3 does not point to the boundary with the caller's stack frame.

By contrast for g++49:

# g++49 -c -g -std=c++11 -Wall -pedantic builtin_dwarf_cfa.cpp
# /usr/local/bin/objdump -d --prefix-addresses builtin_dwarf_cfa.o | more

builtin_dwarf_cfa.o:     file format elf64-powerpc-freebsd


Disassembly of section .text:
0000000000000000 <._Z1fv> mflr    r0
0000000000000004 <._Z1fv+0x4> std     r0,16(r1)
0000000000000008 <._Z1fv+0x8> std     r31,-8(r1)
000000000000000c <._Z1fv+0xc> stdu    r1,-128(r1)
0000000000000010 <._Z1fv+0x10> mr      r31,r1
0000000000000014 <._Z1fv+0x14> addi    r9,r31,128
0000000000000018 <._Z1fv+0x18> mr      r3,r9
000000000000001c <._Z1fv+0x1c> bl      000000000000001c <._Z1fv+0x1c>
0000000000000020 <._Z1fv+0x20> nop
0000000000000024 <._Z1fv+0x24> addi    r1,r31,128
0000000000000028 <._Z1fv+0x28> ld      r0,16(r1)
000000000000002c <._Z1fv+0x2c> mtlr    r0
0000000000000030 <._Z1fv+0x30> ld      r31,-8(r1)
0000000000000034 <._Z1fv+0x34> blr
0000000000000038 <._Z1fv+0x38> .long 0x0
000000000000003c <._Z1fv+0x3c> .long 0x90001
0000000000000040 <._Z1fv+0x40> lwz     r0,1(r1)

r3 does point to the boundary with the caller's stack frame.

For TARGET_ARCH=powerpc, clang 3.8.0 first:

# clang++ -c -g -std=c++11 -Wall -pedantic builtin_dwarf_cfa.cpp
# /usr/local/bin/objdump -d --prefix-addresses builtin_dwarf_cfa.o

builtin_dwarf_cfa.o:     file format elf32-powerpc-freebsd


Disassembly of section .text:
00000000 <_Z1fv> mflr    r0
00000004 <_Z1fv+0x4> stw     r31,-4(r1)
00000008 <_Z1fv+0x8> stw     r0,4(r1)
0000000c <_Z1fv+0xc> stwu    r1,-16(r1)
00000010 <_Z1fv+0x10> mr      r31,r1
00000014 <_Z1fv+0x14> mr      r3,r31
00000018 <_Z1fv+0x18> bl      00000018 <_Z1fv+0x18>
0000001c <_Z1fv+0x1c> addi    r1,r1,16
00000020 <_Z1fv+0x20> lwz     r0,4(r1)
00000024 <_Z1fv+0x24> lwz     r31,-4(r1)
00000028 <_Z1fv+0x28> mtlr    r0
0000002c <_Z1fv+0x2c> blr

Then g++5 (5.3):

# g++5 -c -g -std=c++11 -Wall -pedantic builtin_dwarf_cfa.cpp
# /usr/local/bin/objdump -d --prefix-addresses builtin_dwarf_cfa.o

builtin_dwarf_cfa.o:     file format elf32-powerpc-freebsd


Disassembly of section .text:
00000000 <_Z1fv> stwu    r1,-16(r1)
00000004 <_Z1fv+0x4> mflr    r0
00000008 <_Z1fv+0x8> stw     r0,20(r1)
0000000c <_Z1fv+0xc> stw     r31,12(r1)
00000010 <_Z1fv+0x10> mr      r31,r1
00000014 <_Z1fv+0x14> addi    r9,r31,16
00000018 <_Z1fv+0x18> mr      r3,r9
0000001c <_Z1fv+0x1c> bl      0000001c <_Z1fv+0x1c>
00000020 <_Z1fv+0x20> nop
00000024 <_Z1fv+0x24> addi    r11,r31,16
00000028 <_Z1fv+0x28> lwz     r0,4(r11)
0000002c <_Z1fv+0x2c> mtlr    r0
00000030 <_Z1fv+0x30> lwz     r31,-4(r11)
00000034 <_Z1fv+0x34> mr      r1,r11
00000038 <_Z1fv+0x38> blr

-- 
You are receiving this mail because:
You are the assignee for the bug.


More information about the freebsd-bugs mailing list