From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by sourceware.org (Postfix) with ESMTPS id 5A9D8385783D for ; Tue, 13 Apr 2021 07:45:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 5A9D8385783D Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tdevries@suse.de X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 6391DB0D1; Tue, 13 Apr 2021 07:45:04 +0000 (UTC) Subject: Re: [PATCH] Add -p native and -e native To: Mark Wielaard Cc: Michael Matz , dwz@sourceware.org, jakub@redhat.com References: <20210409092439.GA17210@delia> <20210409094231.GD30119@wildebeest.org> <47b99234-cfe3-86e3-b359-d3ee480e1399@suse.de> <20210412201400.GA3953@wildebeest.org> From: Tom de Vries Message-ID: <46e4e944-ad50-605e-e914-a468e7fe11ef@suse.de> Date: Tue, 13 Apr 2021 09:45:03 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: <20210412201400.GA3953@wildebeest.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.2 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham 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: Tue, 13 Apr 2021 07:45:06 -0000 On 4/12/21 10:14 PM, Mark Wielaard wrote: > 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. > Sure, of course. > 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", > Yes. Native is defined by the current implementation as the default endiannes and pointer size of code generated by the compiler used to compile dwz. So if you're using a compiler that by default generates 32-bit while targeting 64-bit platform, then the resulting -p native is 32-bit. > But when does that ever make sense? It doesn't. The current implementation makes sense if you use a native compiler (i.e., generates 64-bit code for a 64-bit platform), and the same holds in a cross-compiling scenario. I think the assumption that was made here is that the implementation is good enough if it gives good results for the native compiler scenario. > Why would one run the 32bit > binary on a 64bit system and wanting the default -p native be 64bit > instead of 32bit? No idea why one would want to run the 32-bit binary on a 64bit system in the first place. But it's possible. If we have an option -p/-e native, it needs to be assigned a semantics in that case. And in the case of using a native compiler, the semantics are accurate. > Wouldn't one install and run the actual "native" > 64-bit binary in that case? Yes, that's what I would do. Thanks, - Tom