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 2D4DA385783D for ; Tue, 13 Apr 2021 10:06:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 2D4DA385783D 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 0DB6830291BE; Tue, 13 Apr 2021 12:06:18 +0200 (CEST) Received: by librem (Postfix, from userid 1000) id BD019C330A; Tue, 13 Apr 2021 12:04:59 +0200 (CEST) Date: Tue, 13 Apr 2021 12:04:59 +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: <20210413100459.GJ3953@wildebeest.org> References: <20210409092439.GA17210@delia> <20210409094231.GD30119@wildebeest.org> <47b99234-cfe3-86e3-b359-d3ee480e1399@suse.de> <20210412201400.GA3953@wildebeest.org> <46e4e944-ad50-605e-e914-a468e7fe11ef@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: Tue, 13 Apr 2021 10:06:22 -0000 Hi Tom, On Tue, Apr 13, 2021 at 10:33:16AM +0200, Tom de Vries wrote: > On 4/13/21 9:45 AM, Tom de Vries wrote: > > On 4/12/21 10:14 PM, Mark Wielaard wrote: > >> 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. So "native" is not actually needed? > FWIW, would this patch address your concerns? > > It adds an option -p/-e self, and when we do: > ... > $ make clean; make CFLAGS="-O2 -g -m32" LDFLAGS=-m32 > ... > we have: > ... > $ ./dwz -? > ... > -p, --multifile-pointer-size > Set pointer size of multifile, in number > of bytes. > Native pointer size is 8. Self pointer > size is 4. > Default value: auto. So the semantics of "self" make sense to me, but the implementation doesn't. My concerns are that "native" has semantics that nobody would use and it introduces a complicated build rule for the "native.o" and defines based on readelf scraping. "self" semantics make sense to me (and I would actually call that "native") but you don't need this complicated trick of generating an .o file and using readelf to create defines. You can simply use sizeof (void *) and #include plus __BYTE_ORDER to define the endian and pointer sizes. So can we just have native or self based on sizeof (void *) and __BYTE_ORDER and get rid of this Makefile trickery? Cheers, Mark