[Bug 207837] www/firefox: clang34 and clang35 crash on i386 with -O2 -fstack-protector (OPTIMIZED_CFLAGS=off)

[bugzilla-noreply]

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

Jan Beich  changed:

   What|Removed |Added

Summary|www/firefox: clang34 and|www/firefox: clang34 and
   |clang35 crash on i386 with  |clang35 crash on i386 with
   |-O2 -fstack-protector   |-O2 -fstack-protector
   ||(OPTIMIZED_CFLAGS=off)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

[Bug 207837] www/firefox: clang34 and clang35 crash on i386 with -O2 -fstack-protector

[bugzilla-noreply]

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

--- Comment #4 from Jan Beich  ---
(In reply to Vikash Badal from comment #0)
> c++: note: diagnostic msg: Error generating preprocessed source(s).

This probably means we have to shave Unified_cpp_protocol_websocket0.cpp of
extra code manually. Firefox no longer supports non-unified build.

Steps to reproduce:
$ cd www/firefox
$ make
$ pkg install clang34
$ cd $(make -V WRKSRC)
$ clang++34 -m32 -o Unified_cpp_protocol_websocket0.o -c -I
obj-*/dist/stl_wrappers -I obj-*/dist/system_wrappers -include
config/gcc_hidden.h -DOS_POSIX=1 -DOS_FREEBSD=1 -DOS_BSD=1
-DSTATIC_EXPORTABLE_JS_API -DMOZILLA_INTERNAL_API -DIMPL_LIBXUL
-Inetwerk/protocol/websocket -I. -I obj-*/ipc/ipdl/_ipdlheaders
-Iipc/chromium/src -Iipc/glue -Idom/base -Inetwerk/base -I obj-*/dist/include 
-I/usr/local/include/nspr -I/usr/local/include/nss -I/usr/local/include/nss/nss
-I/usr/local/include -I/usr/local/include  -I/usr/local/include/pixman-1  
-fPIC  -DMOZILLA_CLIENT -include obj-*/mozilla-config.h -Qunused-arguments
-isystem/usr/local/include -DLIBICONV_PLUG  -Qunused-arguments -Wall
-Wempty-body -Woverloaded-virtual -Wsign-compare -Wwrite-strings
-Wno-invalid-offsetof -Wno-inline-new-delete -Wno-c++0x-extensions
-Wno-extended-offsetof -Wno-unknown-warning-option -Wno-return-type-c-linkage
-O2 -pipe -DLIBICONV_PLUG -fstack-protector -fno-strict-aliasing
-DLIBICONV_PLUG -fno-exceptions -fno-strict-aliasing -fno-rtti
-ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno
-std=gnu++0x -pipe  -DNDEBUG -DTRIMMED -fno-omit-frame-pointer 
obj-*/netwerk/protocol/websocket/Unified_cpp_protocol_websocket0.cpp

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Ulrich Weigand has confirmed 3 of my 4 llvm bug submittals for clang 3.8.0 targeting powerpc/powerpc64. . .

[Mark Millard]

On 2016-Mar-9, at 11:16 AM, Mark Millard  wrote:
> 
> [He also includes a note about ELFV2 ABI for powerpc64le.]
> 
> Quoting llvm 26856 Comment 6 (he put the text in the 26856 submittal but the 
> content also covers 26519 and most of 26844):
> 
>> Ulrich Weigand 2016-03-09 11:53:17 CST
>> 
>> Yes, there's indeed a couple of problems here, which affect different areas.
>> 
>> 1) On 32-bit ppc, LLVM violates the ABI by storing below the stack pointer 
>> even though the ABI does not provide a "red zone".  This affects every 
>> function with a stack frame, and could in theory lead to spurious crashes 
>> when an asynchronous signal overwrites this area.  This seems to be a known 
>> issue; the source code contains FIXME lines:
>>// FIXME: On PPC32 SVR4, we must not spill before claiming the stackframe.
>> 
>> 2) In some scenarios, registers may be spilled/restored twice to the stack.  
>> This happens because while most of the spilling happens in 
>> PPCFrameLowering::spillCalleeSavedRegisters, a few selected registers are 
>> also spilled in PPCFrameLowering::emitPrologue.  Those registers are the 
>> frame pointer, base pointer, PIC base pointer, link register, and condition 
>> code register.  For the latter two, code ensures that they can never be 
>> spilled in both places (for CR, there is extra code in 
>> spillCalleeSavedRegisters; for LR, the register is removed from SavedRegs in 
>> determineCalleeSaves).
>> 
>> However, for FP, BP, and PBP, nothing ensures the registers are not spilled 
>> twice.  It is probably *rare* for this to happen, because the register 
>> allocator will not use those registers within the function if they're needed 
>> for their special purpose, but it can happen in rare cases.  This includes 
>> the case of a system unwinder routine that uses __builtin_unwind_init, but 
>> could also include other routines that clobber one of those registers, e.g. 
>> the following case:
>> 
>> void func (void);
>> 
>> void test (void)
>> {
>>  func ();
>>  asm ("nop" : : : "31");
>> }
>> 
>> When it happens that a register is spilled twice, the code as such still 
>> works correctly, but the DWARF CFI unwind info associated with the routine 
>> will be broken, which can mess up both C++ exception handling and debugging.
>> 
>> 3) For the specific case of system unwinder routines that use 
>> __builtin_unwind_init and/or __builtin_eh_return, special things need to 
>> happen in the prolog and epilog that are not required for any other routine. 
>>  This in particular includes setting up save areas and CFI records for the 
>> EH data registers (r3 ... r6).  [See bug #26844. ]  For the ELFv2 ABI 
>> (powerpc64le), it also include using three separate save areas for the three 
>> caller-saved condition register fields, so that the EH logic can overwrite 
>> their values independently.
>> 
>> None of this is currently implemented in LLVM, since on Linux generally GCC 
>> is used to build the system unwind libraries, and no other code in the 
>> system ever needs those special constructs.
> 
> 
> ===
> Mark Millard
> markmi at dsl-only.net

One point of his note is wrong: when the 2nd "spill" of a register is after it 
had been changed it makes a bigger difference. I commented back:


> However, for FP, BP, and PBP, nothing ensures the registers are not spilled
> twice.. . .
> 
> When it happens that a register is spilled twice, the code as such still
> works correctly, but the DWARF CFI unwind info associated with the routine
> will be broken, which can mess up both C++ exception handling and debugging.


I will note that the Frame Pointer Register (r31) being saved again to the same 
location but after it was adjusted to match the adjusted stack pointer in the 
callee does not work correctly in that the restore of the Frame Pointer for the 
return to the caller will restore the wrong pointer value.

If the caller then uses r31 without separately also restoring r31 first then it 
will be addressing the wrong memory on the stack.

The observed/reported code sequence had the 2nd r31 store in the callee after 
r31 had been adjusted to match the adjusted stack pointer in the callee.

So more than C++ exception handling and debugging is broken for the reported 
code sequence.



===
Mark Millard
markmi at dsl-only.net

___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Ulrich Weigand has confirmed 3 of my 4 llvm bug submittals for clang 3.8.0 targeting powerpc/powerpc64. . .

[Mark Millard]

[He also includes a note about ELFV2 ABI for powerpc64le.]

Quoting llvm 26856 Comment 6 (he put the text in the 26856 submittal but the 
content also covers 26519 and most of 26844):

> Ulrich Weigand 2016-03-09 11:53:17 CST
> 
> Yes, there's indeed a couple of problems here, which affect different areas.
> 
> 1) On 32-bit ppc, LLVM violates the ABI by storing below the stack pointer 
> even though the ABI does not provide a "red zone".  This affects every 
> function with a stack frame, and could in theory lead to spurious crashes 
> when an asynchronous signal overwrites this area.  This seems to be a known 
> issue; the source code contains FIXME lines:
> // FIXME: On PPC32 SVR4, we must not spill before claiming the stackframe.
> 
> 2) In some scenarios, registers may be spilled/restored twice to the stack.  
> This happens because while most of the spilling happens in 
> PPCFrameLowering::spillCalleeSavedRegisters, a few selected registers are 
> also spilled in PPCFrameLowering::emitPrologue.  Those registers are the 
> frame pointer, base pointer, PIC base pointer, link register, and condition 
> code register.  For the latter two, code ensures that they can never be 
> spilled in both places (for CR, there is extra code in 
> spillCalleeSavedRegisters; for LR, the register is removed from SavedRegs in 
> determineCalleeSaves).
> 
> However, for FP, BP, and PBP, nothing ensures the registers are not spilled 
> twice.  It is probably *rare* for this to happen, because the register 
> allocator will not use those registers within the function if they're needed 
> for their special purpose, but it can happen in rare cases.  This includes 
> the case of a system unwinder routine that uses __builtin_unwind_init, but 
> could also include other routines that clobber one of those registers, e.g. 
> the following case:
> 
> void func (void);
> 
> void test (void)
> {
>   func ();
>   asm ("nop" : : : "31");
> }
> 
> When it happens that a register is spilled twice, the code as such still 
> works correctly, but the DWARF CFI unwind info associated with the routine 
> will be broken, which can mess up both C++ exception handling and debugging.
> 
> 3) For the specific case of system unwinder routines that use 
> __builtin_unwind_init and/or __builtin_eh_return, special things need to 
> happen in the prolog and epilog that are not required for any other routine.  
> This in particular includes setting up save areas and CFI records for the EH 
> data registers (r3 ... r6).  [See bug #26844. ]  For the ELFv2 ABI 
> (powerpc64le), it also include using three separate save areas for the three 
> caller-saved condition register fields, so that the EH logic can overwrite 
> their values independently.
> 
> None of this is currently implemented in LLVM, since on Linux generally GCC 
> is used to build the system unwind libraries, and no other code in the system 
> ever needs those special constructs.


===
Mark Millard
markmi at dsl-only.net

___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

[Bug 207837] www/firefox build fails on i386

[bugzilla-noreply]

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

--- Comment #2 from Vikash Badal  ---
no sure how to obtain this info

lldb37 c++.core

(lldb) bt
error: invalid process


please advise

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

[Bug 207837] www/firefox build fails on i386

[bugzilla-noreply]

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

Jan Beich  changed:

   What|Removed |Added

 CC||freebsd-toolchain@FreeBSD.o
   ||rg

--- Comment #1 from Jan Beich  ---
(In reply to Vikash Badal from comment #0)
> http://anger.where-ever.za.net/~vikashb/firefox-45.0_1,1.log

fetch(1) says "Connection refused".

> fatal error: error in backend: ran out of registers during register allocation
[...]
> diagnostic msg: PLEASE submit ... and include the crash backtrace, 
> preprocessed source, and associated run script.

I don't have 10.2 i386 jail set up but at least 10.1 i386 builds fine[1]. Can
you follow the instruction, so clang maintainer has more chance reproducing the
crash outside of firefox build?

[1]
http://beefy5.nyi.freebsd.org/data/101i386-default/410591/logs/firefox-45.0_1,1.log

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"