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 5E4AE3857C48 for ; Tue, 13 Apr 2021 11:15:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 5E4AE3857C48 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 74998ABE2; Tue, 13 Apr 2021 11:15:40 +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> <46e4e944-ad50-605e-e914-a468e7fe11ef@suse.de> <20210413100459.GJ3953@wildebeest.org> From: Tom de Vries Message-ID: <14f3545a-12e2-9922-cd44-14dcaa5d68ee@suse.de> Date: Tue, 13 Apr 2021 13:15:39 +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: <20210413100459.GJ3953@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 11:15:43 -0000 On 4/13/21 12:04 PM, Mark Wielaard wrote: > 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? > That's not the conclusion I draw based on the argumentation above. >> 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 I think for the use cases that are obvious, self and native have the same semantics and users will pick either. For the non-obvious cases, I'm not sure what usage will look like, so I'd say the solution there is to define options with clear semantics and let the user figure it out. > 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? > I think the current implementation is reliable. I'm not sure about your proposal. Looking at the gcc sources, I find: ... dw2_asm_output_data (1, DWARF2_ADDR_SIZE, "Pointer Size (in bytes)"); ... and: ... #ifndef DWARF2_ADDR_SIZE #define DWARF2_ADDR_SIZE ((POINTER_SIZE + BITS_PER_UNIT - 1) / BITS_PER_UNIT) #endif ... and then some hardcoded overrides in some targets. I don't see any guarantee that the pointer size as used in generated dwarf matches sizeof (void *). So concretely, my fear is that for some target you'd compile dwz natively, then compile some app natively, use -p self and find that the app not matches -p self. Thanks, - Tom