NetBSD Problem Report #39338

From tls@panix.com  Sun Aug 10 16:40:19 2008
Return-Path: <tls@panix.com>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by narn.NetBSD.org (Postfix) with ESMTP id 4E07663BC30
	for <gnats-bugs@gnats.NetBSD.org>; Sun, 10 Aug 2008 16:40:19 +0000 (UTC)
Message-Id: <20080810164011.B1DF2241B3@panix5.panix.com>
Date: Sun, 10 Aug 2008 12:40:11 -0400 (EDT)
From: tls@coyotepoint.com
To: gnats-bugs@gnats.NetBSD.org
Subject: paxctl doesn't work in powerpc -> i386 cross-builds
X-Send-Pr-Version: 3.95

>Number:         39338
>Category:       toolchain
>Synopsis:       paxctl doesn't work in powerpc -> i386 cross-builds
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    toolchain-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Aug 10 16:45:00 +0000 2008
>Last-Modified:  Mon Aug 11 06:05:02 +0000 2008
>Originator:     Thor Lancelot Simon
>Release:        NetBSD 4.99.63
>Organization:
>Environment:
Darwin maxey.hvg.tjls.com 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10
18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh powerpc
Architecture: powerpc
Machine: powerpc
>Description:
	I modified my local build to set MKPIE for a few executables, and
	to mark them for ASLR with PAXCTL_FLAGS=+A.  This works fine in a
	native build or a cross-build from OS X 10.5 on i386.  But in a
	cross-build from OS X 10.4 on powerpc, paxctl appears to
	misinterpret the ELF headers.  Is this a byte-order problem?

	For example:

	/home/tls/nbtools/bin/nbpaxctl +A telnet
	nbpaxctl: Bad ELF size 13312 from `telnet' (maybe it's not an ELF?): Unknown error: 0

	For any executable, the error (and misread size) are always the same.

>How-To-Repeat:
	In a NetBSD/i386 build hosted on Mac OS X (powerpc) 10.4, add
	MKPIE=yes and PAXCTL_FLAGS=+A to the Makefile for any executable.

>Fix:

>Audit-Trail:
From: christos@zoulas.com (Christos Zoulas)
To: gnats-bugs@NetBSD.org, toolchain-manager@netbsd.org, 
	gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Cc: 
Subject: Re: toolchain/39338: paxctl doesn't work in powerpc -> i386 cross-builds
Date: Mon, 11 Aug 2008 02:00:44 -0400

 On Aug 10,  4:45pm, tls@coyotepoint.com (tls@coyotepoint.com) wrote:
 -- Subject: toolchain/39338: paxctl doesn't work in powerpc -> i386 cross-bui

 | >Number:         39338
 | >Category:       toolchain
 | >Synopsis:       paxctl doesn't work in powerpc -> i386 cross-builds
 | >Confidential:   no
 | >Severity:       serious
 | >Priority:       medium
 | >Responsible:    toolchain-manager
 | >State:          open
 | >Class:          sw-bug
 | >Submitter-Id:   net
 | >Arrival-Date:   Sun Aug 10 16:45:00 +0000 2008
 | >Originator:     Thor Lancelot Simon
 | >Release:        NetBSD 4.99.63
 | >Organization:
 | >Environment:
 | Darwin maxey.hvg.tjls.com 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10
 | 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh powerpc
 | Architecture: powerpc
 | Machine: powerpc
 | >Description:
 | 	I modified my local build to set MKPIE for a few executables, and
 | 	to mark them for ASLR with PAXCTL_FLAGS=+A.  This works fine in a
 | 	native build or a cross-build from OS X 10.5 on i386.  But in a
 | 	cross-build from OS X 10.4 on powerpc, paxctl appears to
 | 	misinterpret the ELF headers.  Is this a byte-order problem?
 | 
 | 	For example:
 | 
 | 	/home/tls/nbtools/bin/nbpaxctl +A telnet
 | 	nbpaxctl: Bad ELF size 13312 from `telnet' (maybe it's not an ELF?): Unknown error: 0
 | 
 | 	For any executable, the error (and misread size) are always the same.
 | 
 | >How-To-Repeat:
 | 	In a NetBSD/i386 build hosted on Mac OS X (powerpc) 10.4, add
 | 	MKPIE=yes and PAXCTL_FLAGS=+A to the Makefile for any executable.

 Yes, it is an endian problem. It should auto-detect.

 christos

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.