From owner-freebsd-toolchain@FreeBSD.ORG Sun Mar 31 06:29:15 2013 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2AA2867C; Sun, 31 Mar 2013 06:29:15 +0000 (UTC) (envelope-from jbeich@tormail.org) Received: from outgoing.tormail.org (outgoing.tormail.org [82.221.96.22]) by mx1.freebsd.org (Postfix) with ESMTP id E0817CE5; Sun, 31 Mar 2013 06:29:14 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=internal.tormail.org) by outgoing.tormail.org with esmtp (Exim 4.72) (envelope-from ) id 1UMBlO-0002RF-K7; Sun, 31 Mar 2013 10:29:12 +0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tormail.org; s=tm; h=Message-Id:X-TorMail-User:Content-Type:MIME-Version:References:Date:Subject:Cc:To:From; bh=g4ZMC67m5hkqQPybqHBy7/pJYmhLaH9nUoj0WhUSXqY=; b=OGCGoavL1ddXlFCGU25eK0wBq84ILiY1kyFjQ4HSoSbVyq7uiRlTc4dkOOle37ZJYWzN9IK5+LXZ3X/VJrARfM+hKu5VVukhZSGhR3+O5ePEQoAjebQO9VHiZ5dcw6m+vUALuck78dj3+jtZ+O5i006zjbw/OsEQarAYGlIpPxc=; Received: from jbeich by internal.tormail.org with local (Exim 4.63) (envelope-from ) id 1UMBjC-000FoL-0Y; Sun, 31 Mar 2013 06:26:55 +0000 From: Jan Beich To: Tsurutani Naoki Subject: Re: ports/177224: building www/firefox fails Date: Sun, 31 Mar 2013 08:20:46 +0200 References: <201303290901.AA00161@h115.65.228.10.32118.vlan.kuins.net> MIME-Version: 1.0 Content-Type: text/plain X-TorMail-User: jbeich Message-Id: <1UMBjC-000FoL-0Y@internal.tormail.org> Cc: toolchain@freebsd.org, bug-followup@FreeBSD.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2013 06:29:15 -0000 (toolchain@ may know more about clang-devel behavior) Tsurutani Naoki writes: > building with lang/clang successfully finishes, but firefox crashes > with segmentation fault just after running it. I've asked (privately) devel/llvm maintainer to incorporate r175057 but so far he hasn't responded. http://lists.freebsd.org/pipermail/freebsd-ports/2013-February/081635.html > building without clang successfully finishes, and no errors. > I want a knob to choice the compiler. By setting CC/CXX/CPP you've made the choice. There is no need for a superfluous option for what every port must allow to do. It's just the compiler chosen by default doesn't work. >> ../../dist/bin/libxul.so: undefined reference to `PrepareAndDispatch' >> ../../dist/bin/libxul.so: undefined reference to `invoke_copy_to_stack' >> clang: error: linker command failed with exit code 1 (use -v to see invocation) > > building with lang/clang-devel fails (*1). > (*1) __attribute__((used)) might be ignored with clang-devel (clang 3.3) ? Perhaps, a compiler bug? The following workaround seems to work for clang 3.3 but breaks the build for clang 3.2 / gcc 4.6. --- xpcom/reflect/xptcall/src/md/unix/xptcinvoke_gcc_x86_unix.cpp~ +++ xpcom/reflect/xptcall/src/md/unix/xptcinvoke_gcc_x86_unix.cpp @@ -82,7 +82,7 @@ __asm__ ( "pushl %edx\n\t" /* push this. esp % 16 == 0 */ "movl 0x14(%ebp), %edx\n\t" - "call " SYMBOL_UNDERSCORE "invoke_copy_to_stack\n\t" + "call " SYMBOL_UNDERSCORE "_Z20invoke_copy_to_stackjP13nsXPTCVariantPj\n\t" "movl 0x08(%ebp), %ecx\n\t" /* 'that' */ "movl (%ecx), %edx\n\t" "movl 0x0c(%ebp), %eax\n\t" /* function index */ --- xpcom/reflect/xptcall/src/md/unix/xptcstubs_gcc_x86_unix.cpp~ +++ xpcom/reflect/xptcall/src/md/unix/xptcstubs_gcc_x86_unix.cpp @@ -118,7 +118,7 @@ asm(".text\n\t" SYMBOL_UNDERSCORE "SharedStub:\n\t" "leal 0x08(%esp), %ecx\n\t" "movl 0x04(%esp), %edx\n\t" - "jmp " SYMBOL_UNDERSCORE "PrepareAndDispatch\n\t" + "jmp " SYMBOL_UNDERSCORE "_Z18PrepareAndDispatchjP14nsXPTCStubBasePj\n\t" #if !defined(XP_MACOSX) ".size " SYMBOL_UNDERSCORE "SharedStub,.-" SYMBOL_UNDERSCORE "SharedStub" #endif > using [[gnu::used]] instead of above failed: > % make > ... > /usr/local/work/usr/ports/www/firefox/work/mozilla- > release/xpcom/reflect/xptcall/src/md/unix/xptcinvoke_gcc_x86_unix.cpp:12:13: error: > '__used__' attribute cannot be applied to types > static void ATTRIBUTE_USED __attribute__ ((regparm(3))) > ^ > ../../../../../../../xpcom/reflect/xptcall/src/md/unix/xptc_gcc_x86_unix.h:19:26: note: > expanded from macro 'ATTRIBUTE_USED' > #define ATTRIBUTE_USED [[gnu::__used__]] > ^ > 1 error generated. > % It may be clang 3.3 is more strict with c++11 attributes. clang 3.2 and gcc 4.8 would still warn about incorrect placement. > In file included from xpcom/reflect/xptcall/src/md/unix/xptcinvoke_gcc_x86_unix.cpp:9:0: > xpcom/reflect/xptcall/src/md/unix/xptcinvoke_gcc_x86_unix.cpp: At global scope: > xpcom/reflect/xptcall/src/md/unix/xptc_gcc_x86_unix.h:19:24: warning: attribute ignored [-Wattributes] > #define ATTRIBUTE_USED [[gnu::used]] > ^ > xpcom/reflect/xptcall/src/md/unix/xptcinvoke_gcc_x86_unix.cpp:12:13: note: in expansion of macro 'ATTRIBUTE_USED' > static void ATTRIBUTE_USED __attribute__ ((regparm(3))) > ^ > xpcom/reflect/xptcall/src/md/unix/xptc_gcc_x86_unix.h:19:24: note: an attribute that appertains to a type-specifier is ignored > #define ATTRIBUTE_USED [[gnu::used]] > ^ > xpcom/reflect/xptcall/src/md/unix/xptcinvoke_gcc_x86_unix.cpp:12:13: note: in expansion of macro 'ATTRIBUTE_USED' > static void ATTRIBUTE_USED __attribute__ ((regparm(3))) > ^ And if you put [[gnu::used]] between invoke_copy_to_stack and () the mangling issue happens again. From owner-freebsd-toolchain@FreeBSD.ORG Mon Apr 1 11:06:52 2013 Return-Path: Delivered-To: freebsd-toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 82BB2910 for ; Mon, 1 Apr 2013 11:06:52 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 5BC45348 for ; Mon, 1 Apr 2013 11:06:52 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r31B6qpX033832 for ; Mon, 1 Apr 2013 11:06:52 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r31B6pNP033830 for freebsd-toolchain@FreeBSD.org; Mon, 1 Apr 2013 11:06:51 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 1 Apr 2013 11:06:51 GMT Message-Id: <201304011106.r31B6pNP033830@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-toolchain@FreeBSD.org Subject: Current problem reports assigned to freebsd-toolchain@FreeBSD.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 11:06:52 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o bin/175930 toolchain [headers] clang does not define __STDC_ISO_10646__, de 1 problem total. From owner-freebsd-toolchain@FreeBSD.ORG Tue Apr 2 15:51:29 2013 Return-Path: Delivered-To: toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 44BEA638 for ; Tue, 2 Apr 2013 15:51:29 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 994EABE3 for ; Tue, 2 Apr 2013 15:51:28 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA10270 for ; Tue, 02 Apr 2013 18:51:20 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <515AFE78.1060804@FreeBSD.org> Date: Tue, 02 Apr 2013 18:51:20 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130313 Thunderbird/17.0.4 MIME-Version: 1.0 To: toolchain@FreeBSD.org Subject: clang may generate incorrect dwarf info? X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 15:51:29 -0000 Function signature in FreeBSD source code: void _sx_xunlock(struct sx *sx, const char *file, int line); DWARF (reported by objdump -x -w -W) when compiled with gcc: <1><8337>: Abbrev Number: 63 (DW_TAG_subprogram) <8338> DW_AT_external : 1 <8339> DW_AT_name : (indirect string, offset: 0x48c9): _sx_xunlock <833d> DW_AT_decl_file : 1 <833e> DW_AT_decl_line : 373 <8340> DW_AT_prototyped : 1 <8341> DW_AT_low_pc : 0x13a7 <8349> DW_AT_high_pc : 0x143e <8351> DW_AT_frame_base : 0x3cd3 (location list) <8355> DW_AT_sibling : <84a4> <2><8359>: Abbrev Number: 59 (DW_TAG_formal_parameter) <835a> DW_AT_name : sx <835d> DW_AT_decl_file : 1 <835e> DW_AT_decl_line : 372 <8360> DW_AT_type : <2cac> <8364> DW_AT_location : 0x3d1f (location list) <2><8368>: Abbrev Number: 60 (DW_TAG_formal_parameter) <8369> DW_AT_name : (indirect string, offset: 0x9016): file <836d> DW_AT_decl_file : 1 <836e> DW_AT_decl_line : 372 <8370> DW_AT_type : <1ea> <8374> DW_AT_location : 0x3d8e (location list) <2><8378>: Abbrev Number: 60 (DW_TAG_formal_parameter) <8379> DW_AT_name : (indirect string, offset: 0x12a): line <837d> DW_AT_decl_file : 1 <837e> DW_AT_decl_line : 372 <8380> DW_AT_type : <5f> <8384> DW_AT_location : 0x3dd7 (location list) Ditto when compiled with clang: <1><2c70>: Abbrev Number: 55 (DW_TAG_subprogram) <2c71> DW_AT_name : (indirect string, offset: 0x1817): _sx_xunlock <2c75> DW_AT_decl_file : 1 <2c76> DW_AT_decl_line : 373 <2c78> DW_AT_prototyped : 1 <2c78> DW_AT_external : 1 <2c78> DW_AT_inline : 1 (inlined) <2><2c79>: Abbrev Number: 51 (DW_TAG_formal_parameter) <2c7a> DW_AT_name : (indirect string, offset: 0xd061): line <2c7e> DW_AT_decl_file : 1 <2c7f> DW_AT_decl_line : 373 <2c81> DW_AT_type : <2><2c85>: Abbrev Number: 51 (DW_TAG_formal_parameter) <2c86> DW_AT_name : (indirect string, offset: 0xd056): sx <2c8a> DW_AT_decl_file : 1 <2c8b> DW_AT_decl_line : 373 <2c8d> DW_AT_type : <782c> <2><2c91>: Abbrev Number: 51 (DW_TAG_formal_parameter) <2c92> DW_AT_name : (indirect string, offset: 0xc67): file <2c96> DW_AT_decl_file : 1 <2c97> DW_AT_decl_line : 373 <2c99> DW_AT_type : <32> First, looks like the parameters come in a wrong order. Then: (kgdb) disassemble _sx_xunlock Dump of assembler code for function _sx_xunlock: 0xffffffff805bad20 <_sx_xunlock+0>: push %rbp 0xffffffff805bad21 <_sx_xunlock+1>: mov %rsp,%rbp 0xffffffff805bad24 <_sx_xunlock+4>: push %r14 0xffffffff805bad26 <_sx_xunlock+6>: push %rbx 0xffffffff805bad27 <_sx_xunlock+7>: mov %rdi,%rbx 0xffffffff805bad2a <_sx_xunlock+10>: mov %gs:0x0,%r14 0xffffffff805bad33 <_sx_xunlock+19>: cmpw $0x0,0x10a(%r14) 0xffffffff805bad3c <_sx_xunlock+28>: jne 0xffffffff805bad80 <_sx_xunlock+96> 0xffffffff805bad3e <_sx_xunlock+30>: decw 0x104(%r14) 0xffffffff805bad46 <_sx_xunlock+38>: cmpl $0x0,0xc(%rbx) 0xffffffff805bad4a <_sx_xunlock+42>: jne 0xffffffff805bad6b <_sx_xunlock+75> 0xffffffff805bad4c <_sx_xunlock+44>: mov 0xffffffff80cb4d84,%edi 0xffffffff805bad53 <_sx_xunlock+51>: test %edi,%edi 0xffffffff805bad55 <_sx_xunlock+53>: je 0xffffffff805bad6b <_sx_xunlock+75> 0xffffffff805bad57 <_sx_xunlock+55>: mov %rbx,%rsi 0xffffffff805bad5a <_sx_xunlock+58>: xor %edx,%edx 0xffffffff805bad5c <_sx_xunlock+60>: xor %ecx,%ecx 0xffffffff805bad5e <_sx_xunlock+62>: xor %r8d,%r8d 0xffffffff805bad61 <_sx_xunlock+65>: xor %r9d,%r9d 0xffffffff805bad64 <_sx_xunlock+68>: callq *0xffffffff80cb4d20 0xffffffff805bad6b <_sx_xunlock+75>: mov $0x1,%ecx 0xffffffff805bad70 <_sx_xunlock+80>: mov %r14,%rax 0xffffffff805bad73 <_sx_xunlock+83>: lock cmpxchg %rcx,0x18(%rbx) 0xffffffff805bad79 <_sx_xunlock+89>: sete %al 0xffffffff805bad7c <_sx_xunlock+92>: test %al,%al 0xffffffff805bad7e <_sx_xunlock+94>: je 0xffffffff805bad85 <_sx_xunlock+101> 0xffffffff805bad80 <_sx_xunlock+96>: pop %rbx 0xffffffff805bad81 <_sx_xunlock+97>: pop %r14 0xffffffff805bad83 <_sx_xunlock+99>: pop %rbp 0xffffffff805bad84 <_sx_xunlock+100>: retq 0xffffffff805bad85 <_sx_xunlock+101>: mov %rbx,%rdi 0xffffffff805bad88 <_sx_xunlock+104>: pop %rbx 0xffffffff805bad89 <_sx_xunlock+105>: pop %r14 0xffffffff805bad8b <_sx_xunlock+107>: pop %rbp 0xffffffff805bad8c <_sx_xunlock+108>: jmpq 0xffffffff805bb420 <_sx_xunlock_hard> End of assembler dump. This does not look too inlined to me :-) -- Andriy Gapon