From owner-cvs-ports@FreeBSD.ORG Sun Nov 8 09:29:39 2009 Return-Path: Delivered-To: cvs-ports@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D9A71065679; Sun, 8 Nov 2009 09:29:39 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id 455748FC14; Sun, 8 Nov 2009 09:29:39 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id ADE931E00700; Sun, 8 Nov 2009 10:29:37 +0100 (CET) Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.3/8.14.3) with ESMTP id nA89Q4se053385; Sun, 8 Nov 2009 10:26:04 +0100 (CET) (envelope-from nox@triton8.kn-bremen.de) Received: (from nox@localhost) by triton8.kn-bremen.de (8.14.3/8.14.3/Submit) id nA89Q36F053384; Sun, 8 Nov 2009 10:26:03 +0100 (CET) (envelope-from nox) From: Juergen Lock Date: Sun, 8 Nov 2009 10:26:03 +0100 To: Ian Lance Taylor Message-ID: <20091108092602.GA53221@triton8.kn-bremen.de> References: <200909211911.n8LJBlUK002650@repoman.freebsd.org> <20091103213538.GA61624@triton8.kn-bremen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Dirk Meyer , Juergen Lock , cvs-all@FreeBSD.org, ports-committers@FreeBSD.org, sprewell@jaggeri.com, cvs-ports@FreeBSD.org Subject: Re: cvs commit: ports/devel/gold Makefile X-BeenThere: cvs-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the ports tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 09:29:39 -0000 On Fri, Nov 06, 2009 at 03:52:37PM -0800, Ian Lance Taylor wrote: > Juergen Lock writes: > > > Is this about `exec format error' (ENOEXEC)? We discussed this > > yesterday on irc (hi Sprewell! :) and found out that gold can produce > > executables that won't run on FreeBSD 7 and 8 too (for him it was > > chromium and some test executables on 7.2/i386, for me it was test > > executables on 8/amd64, I couldnt reproduce it here on 8 and 7 i386) - > > and after some debugging using qemu's gdbstub and a FreeBSD 8/amd64 > > livefs guest that I scp'd a problem executable into I found out that > > its this condition in sys/kern/imgact_elf.c that fails: > > http://fxr.watson.org/fxr/source/kern/imgact_elf.c#L721 > > > > 719 if (phdr[i].p_type == PT_INTERP) { > > 720 /* Path to interpreter */ > > 721 if (phdr[i].p_filesz > MAXPATHLEN || > > 722 phdr[i].p_offset + phdr[i].p_filesz > PAGE_SIZE) > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > 723 return (ENOEXEC); > > 724 interp = imgp->image_header + phdr[i].p_offset; > > 725 break; > > 726 } > > 727 } > > > > (gdb) p/x phdr[1].p_offset > > $11 = 0x1174 > > (gdb) p/x phdr[1].p_filesz > > $12 = 0x15 > > (gdb) > > > > So it seems our kernel expects this data (path of the `image activator' > > aka shared linker aka /libexec/ld-elf.so.1) to be in the first page of > > the executable... > > Technically an ELF executable is permitted to have the PT_INTERP > segment anywhere it likes, so I think the kernel is in error here. > Yes it is a kind of... optimistic assumption. :) > However, it is good practice to put PT_INTERP in the first page of the > executable, and I have made that change to gold. So this issue should > be fixed in the next release of the GNU binutils. Cool, thank you! Juergen