bugzilla-nore...@freebsd.org wrote:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207736

            Bug ID: 207736
           Summary: clang 3.8.0/powerpc's _Unwind_RaiseException code
                    generation has messed up r31 (frame pointer)
                    save/restore code (SEGV's can result)
           Product: Base System
           Version: 11.0-CURRENT
          Hardware: ppc
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: bin
          Assignee: freebsd-bugs@FreeBSD.org
          Reporter: mar...@dsl-only.net

[This has been reported on llvm bugzilla: 26856.]

The below causes gdb difficulties for its stack handling: more than just
exception handling is at issue. I just happened to notice it via exception
handling.

Function _Unwind_RaiseException below is from a FreeBSD "buildworld" using
clang 3.8.0.

Dump of assembler code for function _Unwind_RaiseException:
   0x41b2ab80 <+0>:     mflr    r0
   0x41b2ab84 <+4>:     stw     r31,-148(r1)
   0x41b2ab88 <+8>:     stw     r30,-152(r1)
   0x41b2ab8c <+12>:    stw     r0,4(r1)
   0x41b2ab90 <+16>:    stwu    r1,-2992(r1)
   0x41b2ab94 <+20>:    mr      r31,r1
. . .
   0x41b2abe0 <+96>:    stw     r31,2844(r31)
(which replaces the earlier save of the old Frame pointer R31
value with a copy of r1's current  value. Note the offset
relationships with the r1 adjustment: -2992+2844=-148)
. . .
   0x41b2add0 <+592>:   lwz     r31,2844(r31)
(This restores the r1 value that resulted from the "stwu r1,-2992(r1)" into
R31.)
. . .
   0x41b2ae30 <+688>:   lwz     r31,-148(r1)
(This restores the r1 value that resulted from the "stwu r1,-2992(r1)" into
R31.)
. . .

The wrong r31 value is present when _Unwind_RaiseException returns.

But before that while _Unwind_RaiseException is active the C++ exception
handling infrastructure has been given bad r31 information for around
_Unwind_RaiseException's frame.


a little off topic but. i almost downloaded BSD but didn't have time as i was confused ...

BSD 4.3 still has "authentic compatible and fast C"

4.4 - 9.0 has GNU C, which is ok i'm a linux user, i'm used to it for better or worse; it's a dialect that keeps changing and causes many woes

but 9-10.0 uses C Lang - and i'm unsure if that isn't just another mutating dialect (ie, K&R already has issues, %100 not C to start with)

BEFORE I GO ON DISCUSSING THAT:

i go on freeBSD Forums to discuss or what: it never let's me on

does anyone know why freeBSD forums has stopped working for many people with their recent firefox web browsers (many are complaining) (i call ff-20.0 recent) ??
_______________________________________________
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

Reply via email to