Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
To:     linux-kernel@vger.kernel.org
From:   Samuel Bronson <naesten@gmail.com>
Subject: Re: [PATCH v3 1/8] riscv: Avoid unaligned access when relocating modules
Date:   Fri, 25 Feb 2022 23:48:41 -0500
Message-ID: <87zgme6xna.fsf@DESKTOP-5JD7O8D.localdomain>
References: <20220224152456.493365-1-kernel@esmil.dk>
        <20220224152456.493365-2-kernel@esmil.dk>
Mime-Version: 1.0
Content-Type: text/plain
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)
Cancel-Lock: sha1:mColZ0E90tcqhrcGvi1sG17CQfs=
Cc:     linux-riscv@lists.infradead.org
Precedence: bulk

Emil Renner Berthing <kernel@esmil.dk> writes:

> With the C-extension regular 32bit instructions are not
> necessarily aligned on 4-byte boundaries. RISC-V instructions
> are in fact an ordered list of 16bit native-endian
> "parcels", so access the instruction as such.

Hold on a minute, this is what it says in my copy of the Unprivileged
ISA:

,----
| RISC-V base ISAs have either little-endian or big-endian memory systems,
| with the privileged architecture further defining bi-endian operation.
| Instructions are stored in memory as a sequence of 16-bit *little-endian*
| parcels, regardless of memory system endianness.  Parcels forming one
| instruction are stored at increasing halfword addresses, with the
| *lowest-addressed parcel holding the lowest-numbered bits* in the
| instruction specification.
`----
[Emphasis mine.]

In other words, the parcels are little endian, and they're arranged in
little-endian order.  System endianness doesn't matter, it collapses to
plain old little-endian.

(I'm really not sure why they describe the ordering in such a
round-about way; I assume that's the source of the confusion here?)