From patchwork Sun Dec 18 23:25:35 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Samuel Thibault X-Patchwork-Id: 706867 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3thgCf6yg7z9t1T for ; Mon, 19 Dec 2016 10:25:58 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="Z2Z3prkK"; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:references:mime-version :content-type:content-transfer-encoding:in-reply-to; q=dns; s= default; b=eOSLzGpks2kAsLiQWYOovg9pwnzUKwxHZXVFqWBB6fvjeYzMIlRSR knd6rBoum5NAaaJv6uhPFTMWEbnBFbRcuUnGSWQNQTgTP/DnmeJ3WlQ+NrYggO/A fDoJeNN02cPVFmKsmqe8XmjxVJgctHABIJHHVZG9OyJcJRXkxO9UAU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:references:mime-version :content-type:content-transfer-encoding:in-reply-to; s=default; bh=FMcrNTkw2KVeP84gyH2RePiVifI=; b=Z2Z3prkKep9qpIYdJMx7fJoSTq6b IQhFD4v7CUgvlvqByQ3lmZDaRSKLU4CBZWeT5BqXBYIVXWI+xPxLZndlmjbMHdHh iHaxMU8d9RAoI/CVI+gvR1F5x8k9/uyqBR+tLvbE3yjNFYR/40K0U3TX4pMDmznN 6b42Wer0+enLQHI= Received: (qmail 49222 invoked by alias); 18 Dec 2016 23:25:50 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 49213 invoked by uid 89); 18 Dec 2016 23:25:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.1 required=5.0 tests=BAYES_00, SPF_HELO_PASS, SPF_NEUTRAL autolearn=no version=3.3.2 spammy=H*M:home, HX-Envelope-From:sk:samuel., travail, EFAULT X-HELO: hera.aquilenet.fr Received: from hera.aquilenet.fr (HELO hera.aquilenet.fr) (141.255.128.1) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 18 Dec 2016 23:25:39 +0000 Received: from localhost (localhost [127.0.0.1]) by hera.aquilenet.fr (Postfix) with ESMTP id 74D5E8E4D; Mon, 19 Dec 2016 00:25:36 +0100 (CET) Received: from hera.aquilenet.fr ([127.0.0.1]) by localhost (hera.aquilenet.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SYp1lfBGd9TV; Mon, 19 Dec 2016 00:25:35 +0100 (CET) Received: from var.youpi.perso.aquilenet.fr (unknown [IPv6:2a01:cb19:181:c200:3602:86ff:fe2c:6a19]) by hera.aquilenet.fr (Postfix) with ESMTPSA id A84744C; Mon, 19 Dec 2016 00:25:35 +0100 (CET) Received: from samy by var.youpi.perso.aquilenet.fr with local (Exim 4.88) (envelope-from ) id 1cIkpj-00074d-8A; Mon, 19 Dec 2016 00:25:35 +0100 Date: Mon, 19 Dec 2016 00:25:35 +0100 From: Samuel Thibault To: Svante Signell Cc: bug-hurd , Debian GCC Maintainers , gcc-patches Subject: Re: Hurd port for gcc go PATCH 1-4(23) Message-ID: <20161218232535.GT2895@var.home> Mail-Followup-To: Svante Signell , bug-hurd , Debian GCC Maintainers , gcc-patches References: <1480103846.24382.99.camel@gmail.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1480103846.24382.99.camel@gmail.com> User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30) Hello, Svante Signell, on Fri 25 Nov 2016 20:57:26 +0100, wrote: > Another more annoying gnumch/hurd/glibc bug is that the > built program go (go-6 in Debian) gets killed when executed from the > shell vi path, but not when issued directly: /usr/bin/go-6 works fine. >  go-6 > Segmentation fault (core dumped) I've had a quick look by adding printfs in go-main.c and further to see up to where it goes before crashing. It crashes in src/libgo/runtime/go-caller.c in function __go_get_backtrace_state, inside the stat() call in: if (__builtin_strchr (filename, '/') == NULL) filename = NULL; if (stat (filename, &s) < 0 || s.st_size < 1024) filename = NULL; filename of course doesn't start with '/' (it's argv[0]), and thus NULL is passed to stat(). It happens that by luck on Linux this just returns an EFAULT error, but that's sheer luck :) This should probably be turned into e.g.: if (!filename || stat (filename, &s) < 0 || s.st_size < 1024) filename = NULL; as the attached patch does, which should really be applied or done any other way. Then calling go-6 brings this: fatal error: libbacktrace could not find executable to open That's inside src/libbacktrace/fileline.c, the fileline_initialize function, which tries the above filename (and thus fails), then getexecname() (which is not implemented), then /proc/self/exe, which is not implemented, then /proc/curproc/file which is even less implemented. So here it'd be "just" a matter of implementing /proc/self/exe. Samuel Index: runtime/go-caller.c =================================================================== --- runtime/go-caller.c (révision 235086) +++ runtime/go-caller.c (copie de travail) @@ -93,7 +93,7 @@ argv[0] (http://gcc.gnu.org/PR61895). It would be nice to have a better check for whether this file is the real executable. */ - if (stat (filename, &s) < 0 || s.st_size < 1024) + if (!filename || stat (filename, &s) < 0 || s.st_size < 1024) filename = NULL; back_state = backtrace_create_state (filename, 1, error_callback, NULL);