From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (wildebeest.demon.nl [212.238.236.112]) by sourceware.org (Postfix) with ESMTPS id 1811B3958C3C for ; Mon, 12 Apr 2021 20:15:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 1811B3958C3C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mark@klomp.org Received: from librem (deer0x15.wildebeest.org [172.31.17.151]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id BD31830291BE; Mon, 12 Apr 2021 22:15:20 +0200 (CEST) Received: by librem (Postfix, from userid 1000) id E3FF2C3305; Mon, 12 Apr 2021 22:14:00 +0200 (CEST) Date: Mon, 12 Apr 2021 22:14:00 +0200 From: Mark Wielaard To: Tom de Vries Cc: Michael Matz , dwz@sourceware.org, jakub@redhat.com Subject: Re: [PATCH] Add -p native and -e native Message-ID: <20210412201400.GA3953@wildebeest.org> References: <20210409092439.GA17210@delia> <20210409094231.GD30119@wildebeest.org> <47b99234-cfe3-86e3-b359-d3ee480e1399@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47b99234-cfe3-86e3-b359-d3ee480e1399@suse.de> User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: dwz@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Dwz mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2021 20:15:23 -0000 Hi, On Fri, Apr 09, 2021 at 05:58:34PM +0200, Tom de Vries wrote: > >> Except for this narrow multilib case, doesn't this actually make it > >> impossible to do a cross-arch build? > > > > For cross the term "native" doesn't make sense, so it would seem valid to > > simply not support that setting with a cross (not multilib) dwz. I.e. if > > ./native can't be executed assume cross-ness and don't support -p native. > > I've tried yet another variant. Instead of trying to generate an > executable and execute it, we generate an object and test properties > using readelf. > > This should no longer have the cross-build problem. > > WDYT? Can we take a step back, because I think I lost the plot, sorry. Why are we going through all this? So with this when something is build as 32bit it can use 64bit as "native" pointer size. Or if something is cross compiled to little-endian it can still report big-endian as "native", But when does that ever make sense? Why would one run the 32bit binary on a 64bit system and wanting the default -p native be 64bit instead of 32bit? Wouldn't one install and run the actual "native" 64-bit binary in that case? Thanks, Mark