On 4/13/21 9:45 AM, Tom de Vries wrote: > 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. > 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. ... Thanks, - Tom