From owner-freebsd-arm@FreeBSD.ORG Thu Sep 29 15:50:12 2011 Return-Path: Delivered-To: freebsd-arm@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D54371065672 for ; Thu, 29 Sep 2011 15:50:12 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B35B28FC18 for ; Thu, 29 Sep 2011 15:50:12 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p8TFoCDk032810 for ; Thu, 29 Sep 2011 15:50:12 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p8TFoC98032809; Thu, 29 Sep 2011 15:50:12 GMT (envelope-from gnats) Resent-Date: Thu, 29 Sep 2011 15:50:12 GMT Resent-Message-Id: <201109291550.p8TFoC98032809@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-arm@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Naoyuki Tai Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0CE7B106567C for ; Thu, 29 Sep 2011 15:43:46 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from red.freebsd.org (red.freebsd.org [IPv6:2001:4f8:fff6::22]) by mx1.freebsd.org (Postfix) with ESMTP id D77598FC21 for ; Thu, 29 Sep 2011 15:43:45 +0000 (UTC) Received: from red.freebsd.org (localhost [127.0.0.1]) by red.freebsd.org (8.14.4/8.14.4) with ESMTP id p8TFhjOk009712 for ; Thu, 29 Sep 2011 15:43:45 GMT (envelope-from nobody@red.freebsd.org) Received: (from nobody@localhost) by red.freebsd.org (8.14.4/8.14.4/Submit) id p8TFhj06009701; Thu, 29 Sep 2011 15:43:45 GMT (envelope-from nobody) Message-Id: <201109291543.p8TFhj06009701@red.freebsd.org> Date: Thu, 29 Sep 2011 15:43:45 GMT From: Naoyuki Tai To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: arm/161128: gcc 4.2.1 ARM produces bad code with -fstack-protector X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2011 15:50:13 -0000 >Number: 161128 >Category: arm >Synopsis: gcc 4.2.1 ARM produces bad code with -fstack-protector >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-arm >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Sep 29 15:50:12 UTC 2011 >Closed-Date: >Last-Modified: >Originator: Naoyuki Tai >Release: FreeBSD 8.2 Release >Organization: >Environment: FreeBSD 8.2 Release ARM >Description: This is first manifested as arm/154189, but any application or library that uses -fstack-protector causes crash due to the compiler bug. So far, I discovered this in lang/perl5.xx and net/avahi-app. Here is one of manifestation from perl5.10. This is the assembler output of locale.c in perl5.10, with no -fstack-protector. Perl_new_collate: @ args = 0, pretend = 0, frame = 104 @ frame_needed = 1, uses_anonymous_args = 0 mov ip, sp stmfd sp!, {r4, r5, r6, fp, ip, lr, pc} sub fp, ip, #4 sub sp, sp, #104 ldr r6, .L48 .LPIC2: add r6, pc, r6 subs r5, r0, #0 bne .L31 ldr r3, .L48+4 And the data segment .L48 is L48: .word _GLOBAL_OFFSET_TABLE_-(.LPIC2+8) .word PL_collation_name(GOT) Here is the assembler output of locale.c with the -fstack-protector. Perl_new_collate: @ args = 0, pretend = 0, frame = 104 @ frame_needed = 1, uses_anonymous_args = 0 mov ip, sp stmfd sp!, {r4, r5, r6, fp, ip, lr, pc} sub fp, ip, #4 sub sp, sp, #104 ldr r6, .L49 .LPIC2: add r6, pc, r6 ldr r3, .L49+4 And the data segment is .L49: .word _GLOBAL_OFFSET_TABLE_-(.LPIC2+8) .word __stack_chk_guard(GOT) .word PL_collation_name(GOT) Notice the last "ldr r3, .L49+4". It is loading r3 register from __stack_chk_guard(GOT) instead of PL_collation_name(GOT). So, I think that the arm backend has a bug that it is producing wrong offsets in the data segment when the stack protector is used. After noticing this, I took out the "-fstack-protector" from build and the build succeeds. It may be the problem that the combination of -fPIC and -fstack-protector is used. In any case, it is clear that the GCC's arm backend has a bug. cc --version cc (GCC) 4.2.1 20070719 [FreeBSD] Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. >How-To-Repeat: Method 1: Build lang/perl.5.12 on arm. Method 2: Build net/avahi-app on arm and run. avahi-daemon crashes. >Fix: Obviously, the correct fix is to fix the compiler, and I have no idea how. If you need these ports to run without crash, after "make configure", take out the -fstack-protector from the Makefiles and what not under expanded "work" directory. Alternatively, modify the C compiler to ignore -fstack-protector directive. >Release-Note: >Audit-Trail: >Unformatted: