Re: [PATCH] Add -p native and -e native

[Mark Wielaard <mark@klomp.org>]

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 <SIZE|auto|native|self>
>                               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 <endian.h> 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