On 4/9/21 11:42 AM, Mark Wielaard wrote:
> On Fri, Apr 09, 2021 at 11:24:41AM +0200, Tom de Vries wrote:
>> Add option parameter native to options -p and -e.
>>
>> We determine native as the result of:
>> - -p: sizeof (void *)
>> - -e: __BYTE_ORDER__
>> when compiling using CC without CFLAGS, such that if we build dwz with -m32 on
>> x86_64 like so:
>> ...
>> $ make CFLAGS="-m32 -O2 -g" LDFLAGS=-m32
>> ...
>> and we have:
>> ...
>> $ file ./dwz
>> dwz: ELF 32-bit LSB executable, Intel 80386 <SNIP>
>> ...
>> we still have:
>> ...
>> $ ./dwz -?
>>   ...
>>   -p, --multifile-pointer-size <SIZE|auto|native>
>>                               Set pointer size of multifile, in number of bytes.
>>                               Native pointer size is 8.
>>                               Default value: auto.
>> ...
>>
>> Any comments?
> 
> Except for this narrow multilib case, doesn't this actually make it
> impossible to do a cross-arch build?

I think so, yes.  If say we'd have a cross compiler targeting arm but
running on x86_64, then the ./native exec would be for arm but we'd try
to run it on x86_64.

> I don't think this should be a
> compile time option, unless it can derived from the target
> architecture that the dwz binary is build for.

I have an updated patch that does that, AFAIU.

I just wonder whether using the term native for this functionality will
cause confusion.  Perhaps 'self' is a better way of describing this?

And now I also wonder about whether there are architectures where using
__SIZEOF_POINTER__ will be different than what is generated as dwarf
pointer size.  If so, in the previous setup I could have used CC -g,
readelf and grep to find out what is actually used and pass that as a
define to args.c

Perhaps it's a mistake to try to assign any functionality to 'native'
when crosscompiling.

Thanks,
- Tom