public inbox for
 help / color / mirror / Atom feed
From: Tom de Vries <>
To: Mark Wielaard <>
Cc: Michael Matz <>,,
Subject: Re: [PATCH] Add -p native and -e native
Date: Tue, 13 Apr 2021 09:45:03 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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.

- Tom

  reply	other threads:[~2021-04-13  7:45 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-09  9:24 Tom de Vries
2021-04-09  9:42 ` Mark Wielaard
2021-04-09 12:48   ` Tom de Vries
2021-04-09 13:03   ` Michael Matz
2021-04-09 15:58     ` Tom de Vries
2021-04-12 12:33       ` Michael Matz
2021-04-12 15:11         ` Tom de Vries
2021-04-12 19:53           ` [committed] " Tom de Vries
2021-04-12 20:14       ` [PATCH] " Mark Wielaard
2021-04-13  7:45         ` Tom de Vries [this message]
2021-04-13  8:33           ` Tom de Vries
2021-04-13 10:04             ` Mark Wielaard
2021-04-13 11:15               ` Tom de Vries

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).