public inbox for dwz@sourceware.org
 help / color / mirror / Atom feed
From: Tom de Vries <tdevries@suse.de>
To: Mark Wielaard <mark@klomp.org>
Cc: dwz@sourceware.org, jakub@redhat.com, Michael Matz <matz@suse.de>
Subject: Re: [PATCH] Add -p native and -e native
Date: Fri, 9 Apr 2021 14:48:18 +0200	[thread overview]
Message-ID: <2cc8f90d-ec0a-bd8c-f8b8-92643dbd9dbe@suse.de> (raw)
In-Reply-To: <20210409094231.GD30119@wildebeest.org>

[-- Attachment #1: Type: text/plain, Size: 1850 bytes --]

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

[-- Attachment #2: 0001-Add-p-native-and-e-native.patch --]
[-- Type: text/x-patch, Size: 4714 bytes --]

Add -p native and -e native

Add option parameter native to options -p and -e.

We determine native as the result of:
- -p: __SIZEOF_POINTER__
- -e: __BYTE_ORDER__
in dwz.

2021-04-09  Tom de Vries  <tdevries@suse.de>

	* args.c (XSTR, STR, NATIVE_ENDIAN_STRING): New macro.
	(dwz_multi_file_options_help, usage): Mention -p native and -e native.
	(parse_args): Handle -p native and -e native.
	* dwz.1 (-p, -e): Mention native.

---
 args.c | 42 +++++++++++++++++++++++++++++++++++++-----
 dwz.1  | 10 ++++++----
 2 files changed, 43 insertions(+), 9 deletions(-)

diff --git a/args.c b/args.c
index 23bf1d4..5a664cf 100644
--- a/args.c
+++ b/args.c
@@ -32,6 +32,8 @@
 #include "args.h"
 
 #define IMPLIES(A, B) (!((A) && !(B)))
+#define XSTR(s) STR(s)
+#define STR(s) #s
 
 #if DEVEL
 int tracing;
@@ -220,6 +222,14 @@ static struct option_help dwz_single_file_options_help[] =
     "Place the output in OUTFILE." }
 };
 
+#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
+#define NATIVE_ENDIAN_STRING little
+#elif NATIVE_ENDIAN == __ORDER_BIG_ENDIAN__
+#define NATIVE_ENDIAN_STRING big
+#else
+#define NATIVE_ENDIAN_STRING not available
+#endif
+
 /* Describe mult-file command line options.  */
 static struct option_help dwz_multi_file_options_help[] =
 {
@@ -236,10 +246,12 @@ static struct option_help dwz_multi_file_options_help[] =
   { "5", "dwarf-5", NULL, NULL,
     "Emit DWARF 5 standardized supplementary object files instead of"
     " GNU extension .debug_altlink." },
-  { "p", "multifile-pointer-size", "<SIZE|auto>", "auto",
-    "Set pointer size of multifile, in number of bytes." },
-  { "e", "multifile-endian", "<l|b|auto>", "auto",
-    "Set endianity of multifile." },
+  { "p", "multifile-pointer-size", "<SIZE|auto|native>", "auto",
+     "Set pointer size of multifile, in number of bytes."
+    " Native pointer size is " XSTR (__SIZEOF_POINTER__) "." },
+  { "e", "multifile-endian", "<l|b|auto|native>", "auto",
+    "Set endianity of multifile."
+    " Native endianity is " XSTR (NATIVE_ENDIAN_STRING) "." },
   { "j", "jobs", "<n>", "number of processors / 2",
     "Process <n> files in parallel." }
 };
@@ -385,7 +397,7 @@ usage (int failing)
   FILE *stream = failing ? stderr : stdout;
   const char *header_lines[] = {
     "dwz [common options] [-h] [-m COMMONFILE] [-M NAME | -r] [-5]",
-    "    [-p <SIZE|auto>] [-e <l|b|auto>] [-j N] [FILES]",
+    "    [-p <SIZE|auto|native>] [-e <l|b|auto|native>] [-j N] [FILES]",
     "dwz [common options] -o OUTFILE FILE",
     "dwz [ -v | -? ]"
   };
@@ -650,6 +662,11 @@ parse_args (int argc, char *argv[], bool *hardlink, const char **outfile)
 	      multifile_force_ptr_size = 0;
 	      break;
 	    }
+	  if (strcmp (optarg, "native") == 0)
+	    {
+	      multifile_force_ptr_size = __SIZEOF_POINTER__;
+	      break;
+	    }
 	  l = strtoul (optarg, &end, 0);
 	  if (*end != '\0' || optarg == end || (unsigned int) l != l)
 	    error (1, 0, "invalid argument -l %s", optarg);
@@ -662,6 +679,21 @@ parse_args (int argc, char *argv[], bool *hardlink, const char **outfile)
 	      multifile_force_endian = 0;
 	      break;
 	    }
+	  if (strcmp (optarg, "native") == 0)
+	    {
+	      switch (__BYTE_ORDER__)
+		{
+		case __ORDER_LITTLE_ENDIAN__:
+		  multifile_force_endian = ELFDATA2LSB;
+		  break;
+		case __ORDER_BIG_ENDIAN__:
+		  multifile_force_endian = ELFDATA2MSB;
+		  break;
+		default:
+		  error (1, 0, "Cannot determine native endian");
+		}
+	      break;
+	    }
 	  if (strlen (optarg) != 1)
 	    error (1, 0, "invalid argument -l %s", optarg);
 	  switch (optarg[0])
diff --git a/dwz.1 b/dwz.1
index 6fec6ed..1cff329 100644
--- a/dwz.1
+++ b/dwz.1
@@ -77,13 +77,15 @@ the executable or shared library to the file named in the argument
 of the \fB-m\fR option.  Either \fB-M\fR or \fB-r\fR
 option can be specified, but not both.
 .TP
-.B \-p N \-\-multifile-pointer-size <N|auto>
+.B \-p N \-\-multifile-pointer-size <N|auto|native>
 Specify the pointer size of the multifile, in bytes.  If auto, use the
-pointer size of the files, provided they match.
+pointer size of the files, provided they match.  If native, use native pointer
+size, as specified in the help message.
 .TP
-.B \-p <l|b|auto> \-\-multifile-endian <l|b|auto>
+.B \-p <l|b|auto> \-\-multifile-endian <l|b|auto|native>
 Specify the endianity of the multifile.  If auto, use the endianity of
-the files, provided they match.
+the files, provided they match.  If native, use native endianity, as specified
+in the help message.
 .TP
 .B \-q \-\-quiet
 Silence up some of the most common messages.

  reply	other threads:[~2021-04-09 12:48 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 [this message]
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
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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=2cc8f90d-ec0a-bd8c-f8b8-92643dbd9dbe@suse.de \
    --to=tdevries@suse.de \
    --cc=dwz@sourceware.org \
    --cc=jakub@redhat.com \
    --cc=mark@klomp.org \
    --cc=matz@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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).