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 4F5CB3894C39 for ; Mon, 12 Apr 2021 12:33:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 4F5CB3894C39 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=matz@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 667DDAE5C; Mon, 12 Apr 2021 12:33:49 +0000 (UTC) Date: Mon, 12 Apr 2021 12:33:49 +0000 (UTC) From: Michael Matz To: Tom de Vries cc: Mark Wielaard , dwz@sourceware.org, jakub@redhat.com Subject: Re: [PATCH] Add -p native and -e native In-Reply-To: <47b99234-cfe3-86e3-b359-d3ee480e1399@suse.de> Message-ID: References: <20210409092439.GA17210@delia> <20210409094231.GD30119@wildebeest.org> <47b99234-cfe3-86e3-b359-d3ee480e1399@suse.de> User-Agent: Alpine 2.20 (LSU 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, 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: Mon, 12 Apr 2021 12:33:51 -0000 Hello, On Fri, 9 Apr 2021, 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? I think using readelf should work here. But the patch has problems: +#if NATIVE_ENDIAN == little +#define NATIVE_ENDIAN_VAL __ORDER_LITTLE_ENDIAN__ +#elif NATIVE_ENDIAN == big +#define NATIVE_ENDIAN_VAL __ORDER_LITTLE_ENDIAN__ +#else +#define NATIVE_ENDIAN not available +#define NATIVE_ENDIAN_VAL 0 +#endif The preprocessor works different than you seem to assume. Unknown tokens are replaced with 0, so what you've written is the same as: +#if NATIVE_ENDIAN == 0 +#define NATIVE_ENDIAN_VAL __ORDER_LITTLE_ENDIAN__ +#elif NATIVE_ENDIAN == 0 (except if you have defined 'little' and 'big' somewhere, but I can't see that?) Also __ORDER_LITTLE_ENDIAN__ is defined by GCC since 4.6, you might want to check defined-ness of it before using it. And you're setting NATIVE_ENDIAN_VAL to little endian in both if arms. Ciao, Michael.