[{"id":1550313,"web_url":"http://patchwork.ozlabs.org/comment/1550313/","msgid":"","date":"2017-01-10T02:11:07","subject":"Re: bootx_init.c:88: undefined reference to `__stack_chk_fail_local'","submitter":{"id":1036,"url":"http://patchwork.ozlabs.org/api/people/1036/","name":"Christian Kujau","email":"lists@nerdbynature.de"},"content":"On Wed, 4 Jan 2017, Christian Kujau wrote:\n> So, would the following be sufficient? It compiles, but I haven't had a \n> chance to boot yet.\n> \n\nSo, with -fno-stack-protector my GCC 4.9.2 compiles with \nCC_STACKPROTECTOR_STRONG=y but panics during boot:\n\n\nKernel panic - not syncing: stack-protector: Kernel stack is corrupted in: c069278c\nCPU: 0 PIP: 591 Comm: systemd Tainted: G W 4.10.0-rc3-dirty\nCall Trace:\n[ee965bb0] [c0693f5c] panic+0x120/0x274 (unreliable)\n[ee965c10] [c002c568] print_tainted+0x0/0xcc\n[ee965c20] [c069278c] schedule_timeout+0x25c/0x280\n[ee965c80] [c068cc30] io_schedule_timeout+0x90/0xf4\n[ee965ca0] [c00ac870] wait_on_page_bit_killable+0x1Oc/0x170\n[ee965cf0] [c00ad240] __lock_page_or_retry+0xd4/0x12c\n[ee965d10] [c00ad708] filemap_fault+0x470/0x5b0\n[ee965d60] [c00d07c8] __do_fault+0x2c/0x90\n[ee965e40] [c00d4104] handle_mm__fault+0x7c0/0x9cc\n[ee965e00] [c0015a6c] do_page_fault+0x2ec,0x5b4\n[ee965e40] [c0011660] handle_page_fault+0xc/0x80\n--- interrupt: 301 at do_page_fault+0x394/0x5b4\n LR = do_page_fault+0x378,0x5b4\n[ee965f00] [c0015c04] do_page_fault+0x484/0x5b4 (unreliable)\n[ee965f40] [c0011660] handle_page_fault+0xc/0x80\n--- interrupt: 401 at 0x2074d000\n LR = 0x207cff0\n\n\nMaybe ppc32 is not supposed to be built with CC_STACKPROTECTOR ?\n\nThanks,\nChristian.\n\n> \n> diff --git a/arch/powerpc/platforms/powermac/Makefile b/arch/powerpc/platforms/powermac/Makefile\n> index 1eb7b45..c7dcab9 100644\n> --- a/arch/powerpc/platforms/powermac/Makefile\n> +++ b/arch/powerpc/platforms/powermac/Makefile\n> @@ -1,4 +1,4 @@\n> -CFLAGS_bootx_init.o \t\t+= -fPIC\n> +CFLAGS_bootx_init.o \t\t+= -fPIC -fno-stack-protector\n> \n> ifdef CONFIG_FUNCTION_TRACER\n> # Do not trace early boot code\n> \n> \n> Thanks,\n> Christian.\n> -- \n> BOFH excuse #156:\n> \n> Zombie processes haunting the computer\n>","headers":{"Return-Path":"","X-Original-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Received":["from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\t(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3tyFsB5WX8z9t0Z\n\tfor ;\n\tTue, 10 Jan 2017 13:12:14 +1100 (AEDT)","from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3tyFsB4lFJzDqVM\n\tfor ;\n\tTue, 10 Jan 2017 13:12:14 +1100 (AEDT)","from trent.utfs.org (trent.utfs.org [94.185.90.103])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 3tyFr42mnVzDqMF\n\tfor ;\n\tTue, 10 Jan 2017 13:11:13 +1100 (AEDT)","from localhost (localhost [IPv6:::1])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby trent.utfs.org (Postfix) with ESMTPS id 043E85F7A4;\n\tTue, 10 Jan 2017 03:11:08 +0100 (CET)"],"Date":"Mon, 9 Jan 2017 18:11:07 -0800 (PST)","From":"Christian Kujau ","To":"Christophe LEROY ","Subject":"Re: bootx_init.c:88: undefined reference to `__stack_chk_fail_local'","In-Reply-To":"","Message-ID":"","References":"\n\t<81ef821b-8af2-0ee5-ab35-58639548dab7@c-s.fr>\n\t","User-Agent":"Alpine 2.20.999 (DEB 202 2017-01-01)","MIME-Version":"1.0","Content-Type":"text/plain; charset=US-ASCII","X-BeenThere":"linuxppc-dev@lists.ozlabs.org","X-Mailman-Version":"2.1.23","Precedence":"list","List-Id":"Linux on PowerPC Developers Mail List\n\t","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"Benjamin Herrenschmidt , linuxppc-dev@lists.ozlabs.org","Errors-To":"linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org","Sender":"\"Linuxppc-dev\"\n\t"}},{"id":1550399,"web_url":"http://patchwork.ozlabs.org/comment/1550399/","msgid":"<1484022722.21117.8.camel@au1.ibm.com>","date":"2017-01-10T04:32:02","subject":"Re: bootx_init.c:88: undefined reference to `__stack_chk_fail_local'","submitter":{"id":83,"url":"http://patchwork.ozlabs.org/api/people/83/","name":"Benjamin Herrenschmidt","email":"benh@au1.ibm.com"},"content":"On Mon, 2017-01-09 at 18:11 -0800, Christian Kujau wrote:\n> So, with -fno-stack-protector my GCC 4.9.2 compiles with \n> CC_STACKPROTECTOR_STRONG=y but panics during boot:\n\nHow can it make any sense to have -fno-stack-protector and\nCC_STACKPROTECTOR_STRONG=y at the same time ?\n\nBen.","headers":{"Return-Path":"","X-Original-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Received":["from lists.ozlabs.org (lists.ozlabs.org [103.22.144.68])\n\t(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3tyJzn21YJz9sxN\n\tfor ;\n\tTue, 10 Jan 2017 15:33:09 +1100 (AEDT)","from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3tyJzn1FzrzDqSc\n\tfor ;\n\tTue, 10 Jan 2017 15:33:09 +1100 (AEDT)","from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com\n\t[148.163.158.5])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 3tyJyh1DYDzDqN4\n\tfor ;\n\tTue, 10 Jan 2017 15:32:11 +1100 (AEDT)","from pps.filterd (m0098413.ppops.net [127.0.0.1])\n\tby mx0b-001b2d01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id\n\tv0A4SfV1092882\n\tfor ; Mon, 9 Jan 2017 23:32:09 -0500","from e23smtp04.au.ibm.com (e23smtp04.au.ibm.com [202.81.31.146])\n\tby mx0b-001b2d01.pphosted.com with ESMTP id 27vmy4xrfm-1\n\t(version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT)\n\tfor ; Mon, 09 Jan 2017 23:32:09 -0500","from localhost\n\tby e23smtp04.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use\n\tOnly! Violators will be prosecuted\n\tfor from ;\n\tTue, 10 Jan 2017 14:32:06 +1000","from d23dlp03.au.ibm.com (202.81.31.214)\n\tby e23smtp04.au.ibm.com (202.81.31.210) with IBM ESMTP SMTP Gateway:\n\tAuthorized Use Only! Violators will be prosecuted; \n\tTue, 10 Jan 2017 14:32:05 +1000","from d23relay09.au.ibm.com (d23relay09.au.ibm.com [9.185.63.181])\n\tby d23dlp03.au.ibm.com (Postfix) with ESMTP id C90963578052\n\tfor ;\n\tTue, 10 Jan 2017 15:32:04 +1100 (EST)","from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.234.97])\n\tby d23relay09.au.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id\n\tv0A4W4sq3932426\n\tfor ; Tue, 10 Jan 2017 15:32:04 +1100","from d23av03.au.ibm.com (localhost [127.0.0.1])\n\tby d23av03.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id\n\tv0A4W4Xb010249\n\tfor ; Tue, 10 Jan 2017 15:32:04 +1100","from ozlabs.au.ibm.com (ozlabs.au.ibm.com [9.192.253.14])\n\tby d23av03.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id\n\tv0A4W4S4010246; Tue, 10 Jan 2017 15:32:04 +1100","from pasglop (unknown [9.192.163.4])\n\t(using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.au.ibm.com (Postfix) with ESMTPSA id 693BBA0120;\n\tTue, 10 Jan 2017 15:32:02 +1100 (AEDT)"],"Subject":"Re: bootx_init.c:88: undefined reference to `__stack_chk_fail_local'","From":"Benjamin Herrenschmidt ","To":"Christian Kujau , Christophe LEROY\n\t","Date":"Mon, 09 Jan 2017 22:32:02 -0600","In-Reply-To":"","References":"\n\t<81ef821b-8af2-0ee5-ab35-58639548dab7@c-s.fr>\n\t\n\t","Organization":"IBM Australia","Content-Type":"text/plain; charset=\"UTF-8\"","X-Mailer":"Evolution 3.22.3 (3.22.3-1.fc25) ","Mime-Version":"1.0","Content-Transfer-Encoding":"8bit","X-TM-AS-MML":"disable","X-Content-Scanned":"Fidelis XPS MAILER","x-cbid":"17011004-0012-0000-0000-00000201EE06","X-IBM-AV-DETECTION":"SAVI=unused REMOTE=unused XFE=unused","x-cbparentid":"17011004-0013-0000-0000-000006C86F6A","Message-Id":"<1484022722.21117.8.camel@au1.ibm.com>","X-Proofpoint-Virus-Version":"vendor=fsecure engine=2.50.10432:, ,\n\tdefinitions=2017-01-10_03:, , signatures=0","X-Proofpoint-Spam-Details":"rule=outbound_notspam policy=outbound score=0\n\tspamscore=0 suspectscore=0\n\tmalwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam\n\tadjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000\n\tdefinitions=main-1701100060","X-BeenThere":"linuxppc-dev@lists.ozlabs.org","X-Mailman-Version":"2.1.23","Precedence":"list","List-Id":"Linux on PowerPC Developers Mail List\n\t","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Reply-To":"benh@au1.ibm.com","Cc":"linuxppc-dev@lists.ozlabs.org","Errors-To":"linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org","Sender":"\"Linuxppc-dev\"\n\t"}},{"id":1550529,"web_url":"http://patchwork.ozlabs.org/comment/1550529/","msgid":"","date":"2017-01-10T06:26:15","subject":"Re: bootx_init.c:88: undefined reference to `__stack_chk_fail_local'","submitter":{"id":5234,"url":"http://patchwork.ozlabs.org/api/people/5234/","name":"Christophe Leroy","email":"christophe.leroy@c-s.fr"},"content":"Le 10/01/2017 à 03:11, Christian Kujau a écrit :\n> On Wed, 4 Jan 2017, Christian Kujau wrote:\n>> So, would the following be sufficient? It compiles, but I haven't had a\n>> chance to boot yet.\n>>\n>\n> So, with -fno-stack-protector my GCC 4.9.2 compiles with\n> CC_STACKPROTECTOR_STRONG=y but panics during boot:\n>\n>\n>\n> Maybe ppc32 is not supposed to be built with CC_STACKPROTECTOR ?\n\nIndeed, the latest versions of GCC don't use anymore the global variable \n__stack_chk_guard as canary value, but a value stored at -0x7008(r2). \nThis is not compatible with the current implementation of the kernel \nwith uses r2 as a pointeur to current task struct.\nSo until we fix it, I don't think CC_STACKPROTECTOR is usable on PPC \nwith modern versions of GCC.\n\nChristophe\n\n>\n> Thanks,\n> Christian.\n>\n>>\n>> diff --git a/arch/powerpc/platforms/powermac/Makefile b/arch/powerpc/platforms/powermac/Makefile\n>> index 1eb7b45..c7dcab9 100644\n>> --- a/arch/powerpc/platforms/powermac/Makefile\n>> +++ b/arch/powerpc/platforms/powermac/Makefile\n>> @@ -1,4 +1,4 @@\n>> -CFLAGS_bootx_init.o \t\t+= -fPIC\n>> +CFLAGS_bootx_init.o \t\t+= -fPIC -fno-stack-protector\n>>\n>> ifdef CONFIG_FUNCTION_TRACER\n>> # Do not trace early boot code\n>>\n>>\n>> Thanks,\n>> Christian.\n>> --\n>> BOFH excuse #156:\n>>\n>> Zombie processes haunting the computer\n>>\n>","headers":{"Return-Path":"","X-Original-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Received":["from lists.ozlabs.org (lists.ozlabs.org [103.22.144.68])\n\t(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3tyMWS1FTrz9snk\n\tfor ;\n\tTue, 10 Jan 2017 17:27:16 +1100 (AEDT)","from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3tyMWS0RhdzDqQG\n\tfor ;\n\tTue, 10 Jan 2017 17:27:16 +1100 (AEDT)","from pegase1.c-s.fr (pegase1.c-s.fr [93.17.236.30])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 3tyMVM35sxzDqGl\n\tfor ;\n\tTue, 10 Jan 2017 17:26:19 +1100 (AEDT)","from localhost (unknown [192.168.12.234])\n\tby localhost (Postfix) with ESMTP id 3tyMVJ3C5Vz9ttFF;\n\tTue, 10 Jan 2017 07:26:16 +0100 (CET)","from pegase1.c-s.fr ([192.168.12.234])\n\tby localhost (pegase1.c-s.fr [192.168.12.234]) (amavisd-new,\n\tport 10024)\n\twith ESMTP id lw_4y36TOSGx; Tue, 10 Jan 2017 07:26:16 +0100 (CET)","from messagerie.si.c-s.fr (messagerie.si.c-s.fr [192.168.25.192])\n\tby pegase1.c-s.fr (Postfix) with ESMTP id 3tyMVJ2fj6z9ttF4;\n\tTue, 10 Jan 2017 07:26:16 +0100 (CET)","from localhost (localhost [127.0.0.1])\n\tby messagerie.si.c-s.fr (Postfix) with ESMTP id 651CF8B8EF;\n\tTue, 10 Jan 2017 07:26:16 +0100 (CET)","from messagerie.si.c-s.fr ([127.0.0.1])\n\tby localhost (messagerie.si.c-s.fr [127.0.0.1]) (amavisd-new,\n\tport 10023)\n\twith ESMTP id OgXKvV3tTUiw; Tue, 10 Jan 2017 07:26:16 +0100 (CET)","from [127.0.0.1] (unknown [192.168.232.10])\n\tby messagerie.si.c-s.fr (Postfix) with ESMTP id 1B5C98B8E6;\n\tTue, 10 Jan 2017 07:26:16 +0100 (CET)"],"X-Virus-Scanned":["Debian amavisd-new at c-s.fr","amavisd-new at c-s.fr"],"Subject":"Re: bootx_init.c:88: undefined reference to `__stack_chk_fail_local'","To":"Christian Kujau ","References":"\n\t<81ef821b-8af2-0ee5-ab35-58639548dab7@c-s.fr>\n\t\n\t","From":"Christophe LEROY ","Message-ID":"","Date":"Tue, 10 Jan 2017 07:26:15 +0100","User-Agent":"Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101\n\tThunderbird/45.6.0","MIME-Version":"1.0","In-Reply-To":"","Content-Type":"text/plain; charset=windows-1252; format=flowed","Content-Transfer-Encoding":"8bit","X-BeenThere":"linuxppc-dev@lists.ozlabs.org","X-Mailman-Version":"2.1.23","Precedence":"list","List-Id":"Linux on PowerPC Developers Mail List\n\t","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"Benjamin Herrenschmidt , linuxppc-dev@lists.ozlabs.org","Errors-To":"linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org","Sender":"\"Linuxppc-dev\"\n\t"}},{"id":1551114,"web_url":"http://patchwork.ozlabs.org/comment/1551114/","msgid":"","date":"2017-01-10T18:46:23","subject":"Re: bootx_init.c:88: undefined reference to `__stack_chk_fail_local'","submitter":{"id":1036,"url":"http://patchwork.ozlabs.org/api/people/1036/","name":"Christian Kujau","email":"lists@nerdbynature.de"},"content":"On Mon, 9 Jan 2017, Benjamin Herrenschmidt wrote:\n> On Mon, 2017-01-09 at 18:11 -0800, Christian Kujau wrote:\n> > So, with -fno-stack-protector my GCC 4.9.2 compiles with \n> > CC_STACKPROTECTOR_STRONG=y but panics during boot:\n> \n> How can it make any sense to have -fno-stack-protector and\n> CC_STACKPROTECTOR_STRONG=y at the same time ?\n\nI've set -fno-stack-protector only for bootx_init.c, as laid out in the \ndiff I posted. This way the kernel at least compiled.\n\nThanks,\nChristian.","headers":{"Return-Path":"","X-Original-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Received":["from lists.ozlabs.org (lists.ozlabs.org [103.22.144.68])\n\t(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3tygxg2yK9z9t6g\n\tfor ;\n\tWed, 11 Jan 2017 05:47:35 +1100 (AEDT)","from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3tygxg28xPzDqVJ\n\tfor ;\n\tWed, 11 Jan 2017 05:47:35 +1100 (AEDT)","from trent.utfs.org (trent.utfs.org [IPv6:2a03:3680:0:3::67])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 3tygwS1H4RzDqKM\n\tfor ;\n\tWed, 11 Jan 2017 05:46:29 +1100 (AEDT)","from localhost (localhost [IPv6:::1])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby trent.utfs.org (Postfix) with ESMTPS id D91835FADC;\n\tTue, 10 Jan 2017 19:46:23 +0100 (CET)"],"Date":"Tue, 10 Jan 2017 10:46:23 -0800 (PST)","From":"Christian Kujau ","To":"Benjamin Herrenschmidt ","Subject":"Re: bootx_init.c:88: undefined reference to `__stack_chk_fail_local'","In-Reply-To":"<1484022722.21117.8.camel@au1.ibm.com>","Message-ID":"","References":"\n\t<81ef821b-8af2-0ee5-ab35-58639548dab7@c-s.fr>\n\t\n\t\n\t<1484022722.21117.8.camel@au1.ibm.com>","User-Agent":"Alpine 2.20.999 (DEB 202 2017-01-01)","MIME-Version":"1.0","Content-Type":"text/plain; charset=UTF-8","Content-Transfer-Encoding":"8BIT","X-BeenThere":"linuxppc-dev@lists.ozlabs.org","X-Mailman-Version":"2.1.23","Precedence":"list","List-Id":"Linux on PowerPC Developers Mail List\n\t","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"linuxppc-dev@lists.ozlabs.org","Errors-To":"linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org","Sender":"\"Linuxppc-dev\"\n\t"}},{"id":1552434,"web_url":"http://patchwork.ozlabs.org/comment/1552434/","msgid":"<20170111225440.GQ28613@gate.crashing.org>","date":"2017-01-11T22:54:41","subject":"Re: bootx_init.c:88: undefined reference to `__stack_chk_fail_local'","submitter":{"id":134,"url":"http://patchwork.ozlabs.org/api/people/134/","name":"Segher Boessenkool","email":"segher@kernel.crashing.org"},"content":"On Tue, Jan 10, 2017 at 07:26:15AM +0100, Christophe LEROY wrote:\n> >Maybe ppc32 is not supposed to be built with CC_STACKPROTECTOR ?\n> \n> Indeed, the latest versions of GCC don't use anymore the global variable \n> __stack_chk_guard as canary value, but a value stored at -0x7008(r2). \n> This is not compatible with the current implementation of the kernel \n> with uses r2 as a pointeur to current task struct.\n> So until we fix it, I don't think CC_STACKPROTECTOR is usable on PPC \n> with modern versions of GCC.\n\nI still wonder what changed. Nothing relevant has changed for ten years\nor whatever as far as I see; unless it is just the -fstack-protector-strong\nthat makes it fail now. Curious.\n\n\nSegher","headers":{"Return-Path":"","X-Original-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Received":["from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\t(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3tzPPl5zPxz9vDh\n\tfor ;\n\tThu, 12 Jan 2017 09:55:55 +1100 (AEDT)","from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3tzPPl5C7kzDqTm\n\tfor ;\n\tThu, 12 Jan 2017 09:55:55 +1100 (AEDT)","from gate.crashing.org (gate.crashing.org [63.228.1.57])\n\t(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 3tzPNf5QFWzDqNL\n\tfor ;\n\tThu, 12 Jan 2017 09:54:58 +1100 (AEDT)","from gate.crashing.org (localhost.localdomain [127.0.0.1])\n\tby gate.crashing.org (8.14.1/8.13.8) with ESMTP id v0BMsh5i005859;\n\tWed, 11 Jan 2017 16:54:43 -0600","(from segher@localhost)\n\tby gate.crashing.org (8.14.1/8.14.1/Submit) id v0BMsfiB005857;\n\tWed, 11 Jan 2017 16:54:41 -0600"],"Date":"Wed, 11 Jan 2017 16:54:41 -0600","From":"Segher Boessenkool ","To":"Christophe LEROY ","Subject":"Re: bootx_init.c:88: undefined reference to `__stack_chk_fail_local'","Message-ID":"<20170111225440.GQ28613@gate.crashing.org>","References":"\n\t<81ef821b-8af2-0ee5-ab35-58639548dab7@c-s.fr>\n\t\n\t\n\t","Mime-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"","User-Agent":"Mutt/1.4.2.3i","X-BeenThere":"linuxppc-dev@lists.ozlabs.org","X-Mailman-Version":"2.1.23","Precedence":"list","List-Id":"Linux on PowerPC Developers Mail List\n\t","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"Christian Kujau ,\n\tBenjamin Herrenschmidt , linuxppc-dev@lists.ozlabs.org","Errors-To":"linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org","Sender":"\"Linuxppc-dev\"\n\t"}},{"id":1552820,"web_url":"http://patchwork.ozlabs.org/comment/1552820/","msgid":"<1c81ce1a-33ca-7ba4-56f5-976935deb609@c-s.fr>","date":"2017-01-12T07:52:25","subject":"Re: bootx_init.c:88: undefined reference to `__stack_chk_fail_local'","submitter":{"id":5234,"url":"http://patchwork.ozlabs.org/api/people/5234/","name":"Christophe Leroy","email":"christophe.leroy@c-s.fr"},"content":"Le 11/01/2017 à 23:54, Segher Boessenkool a écrit :\n> On Tue, Jan 10, 2017 at 07:26:15AM +0100, Christophe LEROY wrote:\n>>> Maybe ppc32 is not supposed to be built with CC_STACKPROTECTOR ?\n>>\n>> Indeed, the latest versions of GCC don't use anymore the global variable\n>> __stack_chk_guard as canary value, but a value stored at -0x7008(r2).\n>> This is not compatible with the current implementation of the kernel\n>> with uses r2 as a pointeur to current task struct.\n>> So until we fix it, I don't think CC_STACKPROTECTOR is usable on PPC\n>> with modern versions of GCC.\n>\n> I still wonder what changed. Nothing relevant has changed for ten years\n> or whatever as far as I see; unless it is just the -fstack-protector-strong\n> that makes it fail now. Curious.\n>\n\nYes, looks like it was changed from global to TLS in 2005 on powerpc. \nIndeed when I implemented STACKPROTECTOR in Kernel on ppc I \ncopied/pasted it from ARM which is (still?) using the global \n__stack_chk_guard, and at first it worked quite well on my powerpc.\n\nx86 has the following option on GCC. Couldn't we have it on powerpc too ?\n\n-mstack-protector-guard=guard\nGenerate stack protection code using canary at\nguard. Supported locations are ‘ global ’ for global canary or ‘ tls\n’ for per-thread canary in the TLS block (the default). This option \nhas effect only when ‘-fstack-protector’ or ‘-fstack-protector-all’ \nis specified.\n\nChristophe","headers":{"Return-Path":"","X-Original-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Received":["from lists.ozlabs.org (lists.ozlabs.org [103.22.144.68])\n\t(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3tzdL30Swvz9t1L\n\tfor ;\n\tThu, 12 Jan 2017 18:53:31 +1100 (AEDT)","from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3tzdL26vdQzDqSh\n\tfor ;\n\tThu, 12 Jan 2017 18:53:30 +1100 (AEDT)","from pegase1.c-s.fr (pegase1.c-s.fr [93.17.236.30])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 3tzdJv3m0WzDqHn\n\tfor ;\n\tThu, 12 Jan 2017 18:52:31 +1100 (AEDT)","from localhost (unknown [192.168.12.234])\n\tby localhost (Postfix) with ESMTP id 3tzdJn4HJkz9ttF4;\n\tThu, 12 Jan 2017 08:52:25 +0100 (CET)","from pegase1.c-s.fr ([192.168.12.234])\n\tby localhost (pegase1.c-s.fr [192.168.12.234]) (amavisd-new,\n\tport 10024)\n\twith ESMTP id 3m0uN9np1m09; Thu, 12 Jan 2017 08:52:25 +0100 (CET)","from messagerie.si.c-s.fr (messagerie.si.c-s.fr [192.168.25.192])\n\tby pegase1.c-s.fr (Postfix) with ESMTP id 3tzdJn3YNxz9ttDs;\n\tThu, 12 Jan 2017 08:52:25 +0100 (CET)","from localhost (localhost [127.0.0.1])\n\tby messagerie.si.c-s.fr (Postfix) with ESMTP id B2AB78B889;\n\tThu, 12 Jan 2017 08:52:25 +0100 (CET)","from messagerie.si.c-s.fr ([127.0.0.1])\n\tby localhost (messagerie.si.c-s.fr [127.0.0.1]) (amavisd-new,\n\tport 10023)\n\twith ESMTP id bgNLIrCSCANb; Thu, 12 Jan 2017 08:52:25 +0100 (CET)","from [127.0.0.1] (po15451.idsi0.si.c-s.fr [172.25.231.2])\n\tby messagerie.si.c-s.fr (Postfix) with ESMTP id 8786D8B888;\n\tThu, 12 Jan 2017 08:52:25 +0100 (CET)"],"X-Virus-Scanned":["Debian amavisd-new at c-s.fr","amavisd-new at c-s.fr"],"Subject":"Re: bootx_init.c:88: undefined reference to `__stack_chk_fail_local'","To":"Segher Boessenkool ","References":"\n\t<81ef821b-8af2-0ee5-ab35-58639548dab7@c-s.fr>\n\t\n\t\n\t\n\t<20170111225440.GQ28613@gate.crashing.org>","From":"Christophe LEROY ","Message-ID":"<1c81ce1a-33ca-7ba4-56f5-976935deb609@c-s.fr>","Date":"Thu, 12 Jan 2017 08:52:25 +0100","User-Agent":"Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101\n\tThunderbird/45.6.0","MIME-Version":"1.0","In-Reply-To":"<20170111225440.GQ28613@gate.crashing.org>","Content-Type":"text/plain; charset=windows-1252; format=flowed","Content-Transfer-Encoding":"8bit","X-BeenThere":"linuxppc-dev@lists.ozlabs.org","X-Mailman-Version":"2.1.23","Precedence":"list","List-Id":"Linux on PowerPC Developers Mail List\n\t","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"Christian Kujau ,\n\tBenjamin Herrenschmidt , linuxppc-dev@lists.ozlabs.org","Errors-To":"linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org","Sender":"\"Linuxppc-dev\"\n\t"}},{"id":1553242,"web_url":"http://patchwork.ozlabs.org/comment/1553242/","msgid":"<7604032b-c9ae-e3ce-fcd5-d9e555559f52@c-s.fr>","date":"2017-01-12T14:42:34","subject":"Re: bootx_init.c:88: undefined reference to `__stack_chk_fail_local'","submitter":{"id":5234,"url":"http://patchwork.ozlabs.org/api/people/5234/","name":"Christophe Leroy","email":"christophe.leroy@c-s.fr"},"content":"Le 12/01/2017 à 08:52, Christophe LEROY a écrit :\n>\n>\n> Le 11/01/2017 à 23:54, Segher Boessenkool a écrit :\n>> On Tue, Jan 10, 2017 at 07:26:15AM +0100, Christophe LEROY wrote:\n>>>> Maybe ppc32 is not supposed to be built with CC_STACKPROTECTOR ?\n>>>\n>>> Indeed, the latest versions of GCC don't use anymore the global variable\n>>> __stack_chk_guard as canary value, but a value stored at -0x7008(r2).\n>>> This is not compatible with the current implementation of the kernel\n>>> with uses r2 as a pointeur to current task struct.\n>>> So until we fix it, I don't think CC_STACKPROTECTOR is usable on PPC\n>>> with modern versions of GCC.\n>>\n>> I still wonder what changed. Nothing relevant has changed for ten years\n>> or whatever as far as I see; unless it is just the\n>> -fstack-protector-strong\n>> that makes it fail now. Curious.\n>>\n>\n> Yes, looks like it was changed from global to TLS in 2005 on powerpc.\n> Indeed when I implemented STACKPROTECTOR in Kernel on ppc I\n> copied/pasted it from ARM which is (still?) using the global\n> __stack_chk_guard, and at first it worked quite well on my powerpc.\n>\n> x86 has the following option on GCC. Couldn't we have it on powerpc too ?\n>\n> -mstack-protector-guard=guard\n> Generate stack protection code using canary at\n> guard. Supported locations are ‘ global ’ for global canary or ‘ tls\n> ’ for per-thread canary in the TLS block (the default). This option\n> has effect only when ‘-fstack-protector’ or ‘-fstack-protector-all’\n> is specified.\n>\n\nFinally, it looks like it is not so easy.\n\nI have three instances of GCC:\n* 4.4.4, home built\n* 4.6.3, from https://www.kernel.org/pub/tools/crosstool/\n* 4.8.3, home built\n\nThe 4.6.3 uses __stack_chk_guard, while the 4.4.4 and 4.8.3 use -28680(r2)\n\nIs it dependent on the way GCC is built ? Then do we have a way to know, \nwhen we compile, which method GCC will use ?\n\nSee details below for each of the 3 GCC versions.\n\nChristophe\n\nUsing built-in specs.\nTarget: ppc-linux\nConfigured with: /root/cldk/gcc-4.4.4/configure --target=ppc-linux \n--with-headers=yes --with-cpu=860 --prefix=/opt/cldk \n--bindir=/opt/cldk/bin --sbindir=/opt/cldk/sbin \n--libexecdir=/opt/cldk/libexec --datadir=/opt/cldk/share \n--sysconfdir=/opt/cldk/etc --libdir=/opt/cldk/lib \n--includedir=/opt/cldk/usr/include --oldincludedir=/opt/cldk/usr/include \n--infodir=/opt/cldk/share/info --mandir=/opt/cldk/share/man \n--enable-languages=c,c++\nThread model: posix\ngcc version 4.4.4 (GCC)\n\n0000007c :\n 7c:\t7c 08 02 a6 \tmflr r0\n 80:\t94 21 ff a0 \tstwu r1,-96(r1)\n 84:\t3c 80 00 00 \tlis r4,0\n\t\t\t86: R_PPC_ADDR16_HA\t.rodata.str1.4+0x1bc\n 88:\t93 c1 00 58 \tstw r30,88(r1)\n 8c:\t93 e1 00 5c \tstw r31,92(r1)\n 90:\t90 01 00 64 \tstw r0,100(r1)\n 94:\t93 81 00 50 \tstw r28,80(r1)\n 98:\t93 a1 00 54 \tstw r29,84(r1)\n 9c:\t38 84 01 bc \taddi r4,r4,444\n\t\t\t9e: R_PPC_ADDR16_LO\t.rodata.str1.4+0x1bc\n a0:\t38 a0 00 09 \tli r5,9\n a4:\t80 02 8f f8 \tlwz r0,-28680(r2)\n a8:\t90 01 00 4c \tstw r0,76(r1)\n\n[...]\n\n fc:\t80 01 00 4c \tlwz r0,76(r1)\n 100:\t81 22 8f f8 \tlwz r9,-28680(r2)\n 104:\t7c 00 4a 79 \txor. r0,r0,r9\n 108:\t39 20 00 00 \tli r9,0\n 10c:\t7f a3 eb 78 \tmr r3,r29\n 110:\t40 82 03 88 \tbne- 498 \n\n[...]\n\n 498:\t48 00 00 01 \tbl 498 \n\t\t\t498: R_PPC_REL24\t__stack_chk_fail\n\n\nUsing built-in specs.\nCOLLECT_GCC=powerpc64-linux-gcc\nCOLLECT_LTO_WRAPPER=/opt/gcc-4.6.3-nolibc/powerpc64-linux/bin/../libexec/gcc/powerpc64-linux/4.6.3/lto-wrapper\nTarget: powerpc64-linux\nConfigured with: /home/tony/buildall/src/gcc/configure \n--target=powerpc64-linux --host=i686-linux-gnu --build=i686-linux-gnu \n--enable-targets=all \n--prefix=/opt/cross/gcc-4.6.3-nolibc/powerpc64-linux/ \n--enable-languages=c --with-newlib --without-headers \n--enable-sjlj-exceptions --with-system-libunwind --disable-nls \n--disable-threads --disable-shared --disable-libmudflap --disable-libssp \n--disable-libgomp --disable-decimal-float --enable-checking=release \n--with-mpfr=/home/tony/buildall/src/sys-i686 \n--with-gmp=/home/tony/buildall/src/sys-i686 --disable-bootstrap \n--disable-libquadmath\nThread model: single\ngcc version 4.6.3 (GCC)\n\n000000c0 :\n c0:\t94 21 ff a0 \tstwu r1,-96(r1)\n c4:\t7c 08 02 a6 \tmflr r0\n c8:\t3c 80 00 00 \tlis r4,0\n\t\t\tca: R_PPC_ADDR16_HA\t.rodata.str1.4+0x50\n cc:\t38 a0 00 09 \tli r5,9\n d0:\t38 84 00 50 \taddi r4,r4,80\n\t\t\td2: R_PPC_ADDR16_LO\t.rodata.str1.4+0x50\n d4:\tbf 81 00 50 \tstmw r28,80(r1)\n d8:\t3f e0 00 00 \tlis r31,0\n\t\t\tda: R_PPC_ADDR16_HA\t__stack_chk_guard\n dc:\t7c 7e 1b 78 \tmr r30,r3\n e0:\t90 01 00 64 \tstw r0,100(r1)\n e4:\t3b ff 00 00 \taddi r31,r31,0\n\t\t\te6: R_PPC_ADDR16_LO\t__stack_chk_guard\n e8:\t80 1f 00 00 \tlwz r0,0(r31)\n ec:\t90 01 00 4c \tstw r0,76(r1)\n\n[...]\n\n 13c:\t81 21 00 4c \tlwz r9,76(r1)\n 140:\t80 1f 00 00 \tlwz r0,0(r31)\n 144:\t7d 29 02 79 \txor. r9,r9,r0\n 148:\t38 00 00 00 \tli r0,0\n 14c:\t7f 83 e3 78 \tmr r3,r28\n 150:\t40 82 03 68 \tbne- 4b8 \n\n[...]\n\n 4b8:\t48 00 00 01 \tbl 4b8 \n\t\t\t4b8: R_PPC_REL24\t__stack_chk_fail\n\n\nUsing built-in specs.\nCOLLECT_GCC=ppc-linux-gcc\nCOLLECT_LTO_WRAPPER=/opt/cldk/libexec/gcc/ppc-linux/4.8.3/lto-wrapper\nTarget: ppc-linux\nConfigured with: /root/cldk/gcc-4.8.3/configure --target=ppc-linux \n--with-headers=yes --with-cpu=860 --prefix=/opt/cldk \n--bindir=/opt/cldk/bin --sbindir=/opt/cldk/sbin \n--libexecdir=/opt/cldk/libexec --datadir=/opt/cldk/share \n--sysconfdir=/opt/cldk/etc --libdir=/opt/cldk/lib \n--includedir=/opt/cldk/usr/include --oldincludedir=/opt/cldk/usr/include \n--infodir=/opt/cldk/share/info --mandir=/opt/cldk/share/man \n--enable-languages=c,c++\nThread model: posix\ngcc version 4.8.3 (GCC)\n\n000000b0 :\n b0:\t7c 08 02 a6 \tmflr r0\n b4:\t94 21 ff a0 \tstwu r1,-96(r1)\n b8:\t3c 80 00 00 \tlis r4,0\n\t\t\tba: R_PPC_ADDR16_HA\t.rodata.str1.4+0x50\n bc:\tbf a1 00 54 \tstmw r29,84(r1)\n c0:\t90 01 00 64 \tstw r0,100(r1)\n c4:\t38 84 00 00 \taddi r4,r4,0\n\t\t\tc6: R_PPC_ADDR16_LO\t.rodata.str1.4+0x50\n c8:\t38 a0 00 09 \tli r5,9\n cc:\t7c 7f 1b 78 \tmr r31,r3\n d0:\t81 22 8f f8 \tlwz r9,-28680(r2)\n d4:\t91 21 00 4c \tstw r9,76(r1)\n\n[...]\n\n 124:\t81 41 00 4c \tlwz r10,76(r1)\n 128:\t81 22 8f f8 \tlwz r9,-28680(r2)\n 12c:\t7d 4a 4a 79 \txor. r10,r10,r9\n 130:\t39 20 00 00 \tli r9,0\n 134:\t40 82 03 70 \tbne 4a4 \n\n[...]\n\n 4a4:\t48 00 00 01 \tbl 4a4 \n\t\t\t4a4: R_PPC_REL24\t__stack_chk_fail","headers":{"Return-Path":"","X-Original-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Received":["from lists.ozlabs.org (lists.ozlabs.org [103.22.144.68])\n\t(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3tzpRL2FHWz9t1Q\n\tfor ;\n\tFri, 13 Jan 2017 01:43:42 +1100 (AEDT)","from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3tzpRL1VVhzDqZy\n\tfor ;\n\tFri, 13 Jan 2017 01:43:42 +1100 (AEDT)","from pegase1.c-s.fr (pegase1.c-s.fr [93.17.236.30])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 3tzpQ70d79zDqVn\n\tfor ;\n\tFri, 13 Jan 2017 01:42:38 +1100 (AEDT)","from localhost (unknown [192.168.12.234])\n\tby localhost (Postfix) with ESMTP id 3tzpQ239Hjz9ttFK;\n\tThu, 12 Jan 2017 15:42:34 +0100 (CET)","from pegase1.c-s.fr ([192.168.12.234])\n\tby localhost (pegase1.c-s.fr [192.168.12.234]) (amavisd-new,\n\tport 10024)\n\twith ESMTP id HdTWadq5Kz5e; Thu, 12 Jan 2017 15:42:34 +0100 (CET)","from messagerie.si.c-s.fr (messagerie.si.c-s.fr [192.168.25.192])\n\tby pegase1.c-s.fr (Postfix) with ESMTP id 3tzpQ22Yqgz9ttF0;\n\tThu, 12 Jan 2017 15:42:34 +0100 (CET)","from localhost (localhost [127.0.0.1])\n\tby messagerie.si.c-s.fr (Postfix) with ESMTP id 331DB8B948;\n\tThu, 12 Jan 2017 15:42:35 +0100 (CET)","from messagerie.si.c-s.fr ([127.0.0.1])\n\tby localhost (messagerie.si.c-s.fr [127.0.0.1]) (amavisd-new,\n\tport 10023)\n\twith ESMTP id oR-XEIn4NzAi; Thu, 12 Jan 2017 15:42:35 +0100 (CET)","from [127.0.0.1] (po15451.idsi0.si.c-s.fr [172.25.231.2])\n\tby messagerie.si.c-s.fr (Postfix) with ESMTP id EADC08B947;\n\tThu, 12 Jan 2017 15:42:34 +0100 (CET)"],"X-Virus-Scanned":["Debian amavisd-new at c-s.fr","amavisd-new at c-s.fr"],"Subject":"Re: bootx_init.c:88: undefined reference to `__stack_chk_fail_local'","To":"Segher Boessenkool ","References":"\n\t<81ef821b-8af2-0ee5-ab35-58639548dab7@c-s.fr>\n\t\n\t\n\t\n\t<20170111225440.GQ28613@gate.crashing.org>\n\t<1c81ce1a-33ca-7ba4-56f5-976935deb609@c-s.fr>","From":"Christophe LEROY ","Message-ID":"<7604032b-c9ae-e3ce-fcd5-d9e555559f52@c-s.fr>","Date":"Thu, 12 Jan 2017 15:42:34 +0100","User-Agent":"Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101\n\tThunderbird/45.6.0","MIME-Version":"1.0","In-Reply-To":"<1c81ce1a-33ca-7ba4-56f5-976935deb609@c-s.fr>","Content-Type":"text/plain; charset=windows-1252; format=flowed","Content-Transfer-Encoding":"8bit","X-BeenThere":"linuxppc-dev@lists.ozlabs.org","X-Mailman-Version":"2.1.23","Precedence":"list","List-Id":"Linux on PowerPC Developers Mail List\n\t","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"Christian Kujau ,\n\tBenjamin Herrenschmidt , linuxppc-dev@lists.ozlabs.org","Errors-To":"linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org","Sender":"\"Linuxppc-dev\"\n\t"}},{"id":1553272,"web_url":"http://patchwork.ozlabs.org/comment/1553272/","msgid":"<1484234447.2492.34.camel@kernel.crashing.org>","date":"2017-01-12T15:20:47","subject":"Re: bootx_init.c:88: undefined reference to `__stack_chk_fail_local'","submitter":{"id":38,"url":"http://patchwork.ozlabs.org/api/people/38/","name":"Benjamin Herrenschmidt","email":"benh@kernel.crashing.org"},"content":"On Thu, 2017-01-12 at 15:42 +0100, Christophe LEROY wrote:\n> The 4.6.3 uses __stack_chk_guard, while the 4.4.4 and 4.8.3 use\n> -28680(r2)\n> \n> Is it dependent on the way GCC is built ? Then do we have a way to\n> know, \n> when we compile, which method GCC will use ?\n> \n> See details below for each of the 3 GCC versions.\n\nI think it depends if you built it along with glibc (so it can produce\nuserspace binaries) or not.\n\nCheers,\nBen.","headers":{"Return-Path":"","X-Original-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Received":["from lists.ozlabs.org (lists.ozlabs.org [103.22.144.68])\n\t(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3tzqHv56b9z9vDh\n\tfor ;\n\tFri, 13 Jan 2017 02:22:19 +1100 (AEDT)","from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3tzqHv4HskzDqjP\n\tfor ;\n\tFri, 13 Jan 2017 02:22:19 +1100 (AEDT)","from gate.crashing.org (gate.crashing.org [63.228.1.57])\n\t(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 3tzqGp13TBzDqSC\n\tfor ;\n\tFri, 13 Jan 2017 02:21:21 +1100 (AEDT)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby gate.crashing.org (8.14.1/8.13.8) with ESMTP id v0CFKgOV015727;\n\tThu, 12 Jan 2017 09:20:43 -0600"],"Message-ID":"<1484234447.2492.34.camel@kernel.crashing.org>","Subject":"Re: bootx_init.c:88: undefined reference to `__stack_chk_fail_local'","From":"Benjamin Herrenschmidt ","To":"Christophe LEROY , Segher Boessenkool\n\t","Date":"Thu, 12 Jan 2017 09:20:47 -0600","In-Reply-To":"<7604032b-c9ae-e3ce-fcd5-d9e555559f52@c-s.fr>","References":"\n\t<81ef821b-8af2-0ee5-ab35-58639548dab7@c-s.fr>\n\t\n\t\n\t\n\t<20170111225440.GQ28613@gate.crashing.org>\n\t<1c81ce1a-33ca-7ba4-56f5-976935deb609@c-s.fr>\n\t<7604032b-c9ae-e3ce-fcd5-d9e555559f52@c-s.fr>","Content-Type":"text/plain; charset=\"UTF-8\"","X-Mailer":"Evolution 3.22.3 (3.22.3-1.fc25) ","Mime-Version":"1.0","Content-Transfer-Encoding":"8bit","X-BeenThere":"linuxppc-dev@lists.ozlabs.org","X-Mailman-Version":"2.1.23","Precedence":"list","List-Id":"Linux on PowerPC Developers Mail List\n\t","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"Christian Kujau , linuxppc-dev@lists.ozlabs.org","Errors-To":"linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org","Sender":"\"Linuxppc-dev\"\n\t"}},{"id":1553525,"web_url":"http://patchwork.ozlabs.org/comment/1553525/","msgid":"<20170112180713.GU28613@gate.crashing.org>","date":"2017-01-12T18:07:14","subject":"Re: bootx_init.c:88: undefined reference to `__stack_chk_fail_local'","submitter":{"id":134,"url":"http://patchwork.ozlabs.org/api/people/134/","name":"Segher Boessenkool","email":"segher@kernel.crashing.org"},"content":"On Thu, Jan 12, 2017 at 09:20:47AM -0600, Benjamin Herrenschmidt wrote:\n> On Thu, 2017-01-12 at 15:42 +0100, Christophe LEROY wrote:\n> > The 4.6.3 uses __stack_chk_guard, while the 4.4.4 and 4.8.3 use\n> > -28680(r2)\n> > \n> > Is it dependent on the way GCC is built ? Then do we have a way to\n> > know, \n> > when we compile, which method GCC will use ?\n> > \n> > See details below for each of the 3 GCC versions.\n> \n> I think it depends if you built it along with glibc (so it can produce\n> userspace binaries) or not.\n\nRight. Tony's compilers are built using a (modified version of) buildall,\nand buildall goes out of its way to build without libc whatsoever, even\nif the configuration (powerpc64-linux, for example) expects one.\n\nWhich leads to TARGET_LIBC_PROVIDES_SSP being undefined (it would normally\nbe true for glibc >= 2.4), and that is all. Mystery solved. Thanks!\n\n\nSegher","headers":{"Return-Path":"","X-Original-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Received":["from lists.ozlabs.org (lists.ozlabs.org [103.22.144.68])\n\t(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3tzv6V0TYsz9t1H\n\tfor ;\n\tFri, 13 Jan 2017 05:14:26 +1100 (AEDT)","from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3tzv6T6rbWzDqlg\n\tfor ;\n\tFri, 13 Jan 2017 05:14:25 +1100 (AEDT)","from gate.crashing.org (gate.crashing.org [63.228.1.57])\n\t(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 3tzv5Q0TDPzDqYp\n\tfor ;\n\tFri, 13 Jan 2017 05:13:29 +1100 (AEDT)","from gate.crashing.org (localhost.localdomain [127.0.0.1])\n\tby gate.crashing.org (8.14.1/8.13.8) with ESMTP id v0CI7J3N000636;\n\tThu, 12 Jan 2017 12:07:19 -0600","(from segher@localhost)\n\tby gate.crashing.org (8.14.1/8.14.1/Submit) id v0CI7FTi000620;\n\tThu, 12 Jan 2017 12:07:15 -0600"],"Date":"Thu, 12 Jan 2017 12:07:14 -0600","From":"Segher Boessenkool ","To":"Benjamin Herrenschmidt ","Subject":"Re: bootx_init.c:88: undefined reference to `__stack_chk_fail_local'","Message-ID":"<20170112180713.GU28613@gate.crashing.org>","References":"\n\t<81ef821b-8af2-0ee5-ab35-58639548dab7@c-s.fr>\n\t\n\t\n\t\n\t<20170111225440.GQ28613@gate.crashing.org>\n\t<1c81ce1a-33ca-7ba4-56f5-976935deb609@c-s.fr>\n\t<7604032b-c9ae-e3ce-fcd5-d9e555559f52@c-s.fr>\n\t<1484234447.2492.34.camel@kernel.crashing.org>","Mime-Version":"1.0","Content-Type":"text/plain; charset=iso-8859-1","Content-Disposition":"inline","Content-Transfer-Encoding":"8bit","In-Reply-To":"<1484234447.2492.34.camel@kernel.crashing.org>","User-Agent":"Mutt/1.4.2.3i","X-BeenThere":"linuxppc-dev@lists.ozlabs.org","X-Mailman-Version":"2.1.23","Precedence":"list","List-Id":"Linux on PowerPC Developers Mail List\n\t","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"Christian Kujau , linuxppc-dev@lists.ozlabs.org","Errors-To":"linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org","Sender":"\"Linuxppc-dev\"\n\t"}},{"id":1554376,"web_url":"http://patchwork.ozlabs.org/comment/1554376/","msgid":"","date":"2017-01-13T12:15:03","subject":"Re: bootx_init.c:88: undefined reference to `__stack_chk_fail_local'","submitter":{"id":5234,"url":"http://patchwork.ozlabs.org/api/people/5234/","name":"Christophe Leroy","email":"christophe.leroy@c-s.fr"},"content":"Le 12/01/2017 à 19:07, Segher Boessenkool a écrit :\n> On Thu, Jan 12, 2017 at 09:20:47AM -0600, Benjamin Herrenschmidt wrote:\n>> On Thu, 2017-01-12 at 15:42 +0100, Christophe LEROY wrote:\n>>> The 4.6.3 uses __stack_chk_guard, while the 4.4.4 and 4.8.3 use\n>>> -28680(r2)\n>>>\n>>> Is it dependent on the way GCC is built ? Then do we have a way to\n>>> know,\n>>> when we compile, which method GCC will use ?\n>>>\n>>> See details below for each of the 3 GCC versions.\n>>\n>> I think it depends if you built it along with glibc (so it can produce\n>> userspace binaries) or not.\n>\n> Right. Tony's compilers are built using a (modified version of) buildall,\n> and buildall goes out of its way to build without libc whatsoever, even\n> if the configuration (powerpc64-linux, for example) expects one.\n>\n> Which leads to TARGET_LIBC_PROVIDES_SSP being undefined (it would normally\n> be true for glibc >= 2.4), and that is all. Mystery solved. Thanks!\n>\n\nIs there a way to know during compilation how the compiler will behave, \nin order to select the correct method ?\n\nI have drafted a new approach in the kernel that uses -0x7008(r2) \ninstead of the global __stack_chk_guard, but how can I select the proper \napproach during kernel compilation in line with the selected GCC ?\n\nChristophe","headers":{"Return-Path":"","X-Original-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Received":["from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\t(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3v0M703rJ7z9sDG\n\tfor ;\n\tFri, 13 Jan 2017 23:16:28 +1100 (AEDT)","from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3v0M7032QlzDqfW\n\tfor ;\n\tFri, 13 Jan 2017 23:16:28 +1100 (AEDT)","from pegase1.c-s.fr (pegase1.c-s.fr [93.17.236.30])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 3v0M5V04mpzDqVJ\n\tfor ;\n\tFri, 13 Jan 2017 23:15:09 +1100 (AEDT)","from localhost (unknown [192.168.12.234])\n\tby localhost (Postfix) with ESMTP id 3v0M5M2CsJz9ttF0;\n\tFri, 13 Jan 2017 13:15:03 +0100 (CET)","from pegase1.c-s.fr ([192.168.12.234])\n\tby localhost (pegase1.c-s.fr [192.168.12.234]) (amavisd-new,\n\tport 10024)\n\twith ESMTP id EZ6e_1FHuorF; Fri, 13 Jan 2017 13:15:03 +0100 (CET)","from messagerie.si.c-s.fr (messagerie.si.c-s.fr [192.168.25.192])\n\tby pegase1.c-s.fr (Postfix) with ESMTP id 3v0M5M1g7mz9ttDr;\n\tFri, 13 Jan 2017 13:15:03 +0100 (CET)","from localhost (localhost [127.0.0.1])\n\tby messagerie.si.c-s.fr (Postfix) with ESMTP id D44658B97C;\n\tFri, 13 Jan 2017 13:15:03 +0100 (CET)","from messagerie.si.c-s.fr ([127.0.0.1])\n\tby localhost (messagerie.si.c-s.fr [127.0.0.1]) (amavisd-new,\n\tport 10023)\n\twith ESMTP id CIc4_FHG5FJk; Fri, 13 Jan 2017 13:15:03 +0100 (CET)","from [127.0.0.1] (po15451.idsi0.si.c-s.fr [172.25.231.2])\n\tby messagerie.si.c-s.fr (Postfix) with ESMTP id ACACD8B95C;\n\tFri, 13 Jan 2017 13:15:03 +0100 (CET)"],"X-Virus-Scanned":["Debian amavisd-new at c-s.fr","amavisd-new at c-s.fr"],"Subject":"Re: bootx_init.c:88: undefined reference to `__stack_chk_fail_local'","To":"Segher Boessenkool ,\n\tBenjamin Herrenschmidt ","References":"\n\t<81ef821b-8af2-0ee5-ab35-58639548dab7@c-s.fr>\n\t\n\t\n\t\n\t<20170111225440.GQ28613@gate.crashing.org>\n\t<1c81ce1a-33ca-7ba4-56f5-976935deb609@c-s.fr>\n\t<7604032b-c9ae-e3ce-fcd5-d9e555559f52@c-s.fr>\n\t<1484234447.2492.34.camel@kernel.crashing.org>\n\t<20170112180713.GU28613@gate.crashing.org>","From":"Christophe LEROY ","Message-ID":"","Date":"Fri, 13 Jan 2017 13:15:03 +0100","User-Agent":"Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101\n\tThunderbird/45.6.0","MIME-Version":"1.0","In-Reply-To":"<20170112180713.GU28613@gate.crashing.org>","Content-Type":"text/plain; charset=windows-1252; format=flowed","Content-Transfer-Encoding":"8bit","X-BeenThere":"linuxppc-dev@lists.ozlabs.org","X-Mailman-Version":"2.1.23","Precedence":"list","List-Id":"Linux on PowerPC Developers Mail List\n\t","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"Christian Kujau , linuxppc-dev@lists.ozlabs.org","Errors-To":"linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org","Sender":"\"Linuxppc-dev\"\n\t"}},{"id":1554382,"web_url":"http://patchwork.ozlabs.org/comment/1554382/","msgid":"<063D6719AE5E284EB5DD2968C1650D6DB02621FA@AcuExch.aculab.com>","date":"2017-01-13T12:23:24","subject":"RE: bootx_init.c:88: undefined reference to `__stack_chk_fail_local'","submitter":{"id":6689,"url":"http://patchwork.ozlabs.org/api/people/6689/","name":"David Laight","email":"David.Laight@ACULAB.COM"},"content":"From: Christophe LEROY\n> Sent: 13 January 2017 12:15\n...\n> > Which leads to TARGET_LIBC_PROVIDES_SSP being undefined (it would normally\n> > be true for glibc >= 2.4), and that is all. Mystery solved. Thanks!\n> >\n> \n> Is there a way to know during compilation how the compiler will behave,\n> in order to select the correct method ?\n> \n> I have drafted a new approach in the kernel that uses -0x7008(r2)\n> instead of the global __stack_chk_guard, but how can I select the proper\n> approach during kernel compilation in line with the selected GCC ?\n\nWorse, how can you ensure that loadable modules are compiled with the\nsame option as the rest of the kernel.\n\n\tDavid","headers":{"Return-Path":"","X-Original-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Received":["from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\t(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3v0MJX2vMfz9sDG\n\tfor ;\n\tFri, 13 Jan 2017 23:24:44 +1100 (AEDT)","from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3v0MJX1v9TzDqhW\n\tfor ;\n\tFri, 13 Jan 2017 23:24:44 +1100 (AEDT)","from smtp-out4.electric.net (smtp-out4.electric.net\n\t[192.162.216.186])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 3v0MHB1DcQzDqFh\n\tfor ;\n\tFri, 13 Jan 2017 23:23:33 +1100 (AEDT)","from 1cS0tC-0001y4-UT by out4c.electric.net with emc1-ok (Exim\n\t4.87) (envelope-from )\n\tid 1cS0tD-00029f-Vh; Fri, 13 Jan 2017 04:23:27 -0800","by emcmailer; Fri, 13 Jan 2017 04:23:27 -0800","from [213.249.233.130] (helo=AcuExch.aculab.com)\n\tby out4c.electric.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.87)\n\t(envelope-from )\n\tid 1cS0tC-0001y4-UT; Fri, 13 Jan 2017 04:23:26 -0800","from ACUEXCH.Aculab.com ([::1]) by AcuExch.aculab.com ([::1]) with\n\tmapi id 14.03.0123.003; Fri, 13 Jan 2017 12:23:24 +0000"],"From":"David Laight ","To":"'Christophe LEROY' , Segher Boessenkool\n\t, Benjamin Herrenschmidt\n\t","Subject":"RE: bootx_init.c:88: undefined reference to `__stack_chk_fail_local'","Thread-Topic":"bootx_init.c:88: undefined reference to\n\t`__stack_chk_fail_local'","Thread-Index":"AQHSbZba6q51EBsuqkK7G1XMXkjwiaE2VA4A","Date":"Fri, 13 Jan 2017 12:23:24 +0000","Message-ID":"<063D6719AE5E284EB5DD2968C1650D6DB02621FA@AcuExch.aculab.com>","References":"\n\t<81ef821b-8af2-0ee5-ab35-58639548dab7@c-s.fr>\n\t\n\t\n\t\n\t<20170111225440.GQ28613@gate.crashing.org>\n\t<1c81ce1a-33ca-7ba4-56f5-976935deb609@c-s.fr>\n\t<7604032b-c9ae-e3ce-fcd5-d9e555559f52@c-s.fr>\n\t<1484234447.2492.34.camel@kernel.crashing.org>\n\t<20170112180713.GU28613@gate.crashing.org>\n\t","In-Reply-To":"","Accept-Language":"en-GB, en-US","Content-Language":"en-US","X-MS-Has-Attach":"","X-MS-TNEF-Correlator":"","x-originating-ip":"[10.202.99.200]","Content-Type":"text/plain; charset=\"Windows-1252\"","Content-Transfer-Encoding":"quoted-printable","MIME-Version":"1.0","X-Outbound-IP":"213.249.233.130","X-Env-From":"David.Laight@ACULAB.COM","X-Proto":"esmtps","X-Revdns":"","X-HELO":"AcuExch.aculab.com","X-TLS":"TLSv1:AES128-SHA:128","X-Authenticated_ID":"","X-PolicySMART":"3396946, 3397078","X-Virus-Status":["Scanned by VirusSMART (c)","Scanned by VirusSMART (s)"],"X-BeenThere":"linuxppc-dev@lists.ozlabs.org","X-Mailman-Version":"2.1.23","Precedence":"list","List-Id":"Linux on PowerPC Developers Mail List\n\t","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"Christian Kujau ,\n\t\"linuxppc-dev@lists.ozlabs.org\" ","Errors-To":"linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org","Sender":"\"Linuxppc-dev\"\n\t"}}]