From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) by sourceware.org (Postfix) with ESMTPS id 994AE386CE69 for ; Thu, 9 Jun 2022 11:21:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 994AE386CE69 Received: by mail-pf1-x42f.google.com with SMTP id b135so20801126pfb.12 for ; Thu, 09 Jun 2022 04:21:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=EcsA5Xk9qdF4JRhDkCDDD5AUfavauyZNCQMYPZiGgkU=; b=M64iapA/xPK0GTMLQUN/dp60GXn29rSUiBE4h0ag6+WrseV7kep46IRtMP6GIlDnGM PC+xWYbhxqr8WBfd0FsjatD/TH31PlHVjOepkEE9ZxTn52f5xpz4Xm6P4hCtdwIe13Ga JuaTn6AkQuWkciuESpQmfWmljPwpijw38vHKgtDk4PXtlZF8xu54oRSKGVg+JFoPZU0Q ugAUA0Ln/voTO+clAsIdQ8/wwjRsWGJFMl42kG6IdzitYujaA5m/GoeM27bs4IK6yaX5 BGO3ae4MedJTGtBHF6Ck77UaB9OPr3w3I9Jxl33KmPMl5UhuHQTbAztt9ZsXrJqUaeyc Ws8g== X-Gm-Message-State: AOAM530JX9UXaA6BfUin4oNDTKyxQq8qS7uhiy0FGVOq9NtBnGHTfvw9 zbYDOvWoDwd7YxaxyRFBkgA= X-Google-Smtp-Source: ABdhPJx3dQx5otB2AfQD2Pnuu4z68uVCX9EHTkr8iDUIIxx6Pt+ix2PoWZysO6R0bgEqotUEbaTxVw== X-Received: by 2002:a63:3184:0:b0:3fc:5893:c866 with SMTP id x126-20020a633184000000b003fc5893c866mr34776237pgx.56.1654773682531; Thu, 09 Jun 2022 04:21:22 -0700 (PDT) Received: from localhost ([2409:10:24a0:4700:e8ad:216a:2a9d:6d0c]) by smtp.gmail.com with ESMTPSA id 5-20020a630105000000b003f27f91135asm17294068pgb.76.2022.06.09.04.21.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Jun 2022 04:21:21 -0700 (PDT) Date: Thu, 9 Jun 2022 20:21:19 +0900 From: Stafford Horne To: Samuel Holland Cc: binutils@sourceware.org, openrisc@lists.librecores.org Subject: Re: [PATCH] or1k: Add support for a little-endian target variant Message-ID: References: <20220609060133.26409-1-samuel@sholland.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220609060133.26409-1-samuel@sholland.org> X-Spam-Status: No, score=-10.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2022 11:21:25 -0000 On Thu, Jun 09, 2022 at 01:01:33AM -0500, Samuel Holland wrote: > While not officially sanctioned by the architecture spec, little-endian > or1k processors do exist in the wild, for example the Allwinner AR100. > Let's add native support for this, instead of hacks like using objcopy > to byteswap ELF file contents. Hello, In general I have no objections to this. If there are processors that hare little endian it makes sense to support it. Do you have any details of how people built for these before? I am curious. > diff --git a/gas/config/tc-or1k.c b/gas/config/tc-or1k.c > index ae4e3452f48..9dc5a46f2e2 100644 > --- a/gas/config/tc-or1k.c > +++ b/gas/config/tc-or1k.c > @@ -58,8 +58,16 @@ const char FLT_CHARS[] = "dD"; > #define OR1K_SHORTOPTS "m:" > const char * md_shortopts = OR1K_SHORTOPTS; > > +enum > +{ > + OPTION_LITTLE_ENDIAN = OPTION_MD_BASE, > + OPTION_BIG_ENDIAN > +}; > + > struct option md_longopts[] = > { > + {"EB", no_argument, NULL, OPTION_BIG_ENDIAN}, > + {"EL", no_argument, NULL, OPTION_LITTLE_ENDIAN}, > {NULL, no_argument, NULL, 0} > }; > size_t md_longopts_size = sizeof (md_longopts); > @@ -67,14 +75,30 @@ size_t md_longopts_size = sizeof (md_longopts); > unsigned long or1k_machine = 0; /* default */ > > int > -md_parse_option (int c ATTRIBUTE_UNUSED, const char * arg ATTRIBUTE_UNUSED) > +md_parse_option (int c, const char * arg ATTRIBUTE_UNUSED) > { > - return 0; > + switch (c) > + { > + case OPTION_BIG_ENDIAN: > + target_big_endian = 1; > + break; > + case OPTION_LITTLE_ENDIAN: > + target_big_endian = 0; > + break; > + default: > + return 0; > + } > + > + return 1; > } > > void > -md_show_usage (FILE * stream ATTRIBUTE_UNUSED) > +md_show_usage (FILE * stream) > { > + fprintf (stream, _(" OR1K-specific assembler options:\n")); > + fprintf (stream, _("\ > + --EB generate code for a big endian machine\n\ > + --EL generate code for a little endian machine\n")); > } Aboce you mention -EB, -EL, here is is --EB, --EL. Does this setup big endian as the default? We should specify that in the options. i.e. "generate code for a big endian machine, this is the default." But I am not sure how that defaulting works now. I will try to build this and understand better. -Stafford