Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Run an MSB executable on a Little Endian operating system

280 views
Skip to first unread message

Frederick Gotham

unread,
Jan 20, 2022, 3:58:08 AM1/20/22
to

I posted this post this morning to the forums for Raspberry Pi and wxWidgets. I'd also like to get opinions here.

I have a Raspberry Pi 2 Model B. The CPU is 32-Bit ARM Cortex A7, which can be configured to run both in Little Endian and Big Endian mode. All the raspberry pies come out of the factory configured for Little Endian. It's also possible with this CPU to switch the endianness just for the current process by executing the CPU instruction "setend be". I have tested this and it works.

I am the author of the network analysis tool, Dynamo, which I wrote in C++ using the wxWidgets cross-platform framework. I've got my program building and running well on Linux, MS-Windows, macOS. This week I've successfully gotten my program to build and run well on my Raspberry Pi 2 Model B in the Pixel desktop environment. I want to build my program for Big Endian to test it (and also just because it sounds cool). If there were a Big Endian image of the raspberry pi operating system that I could load onto my pi, then I'd do that. I don't see one anywhere though.

What I want to do now is build my program for 32-Bit ARM Big Endian and run it on my pi. I've tried building small programs with gcc for Big Endian at the command line, and when I check the executable file type it says "MSB executable" so that means it's Big Endian. (Little Endian is LSB). However when I try to run the MSB executable at the command line, Linux won't run it. It will only run LSB executables.

So here's what my next idea is:

I want to get the source code for wxWidgets, and build it to statically link with every library (including libgcc and libstdc++) to produce an MSB static library. Then I will build my Dynamo program to link statically with every library in order to produce an MSB executable file that is fully self-sufficient (i.e. if you run 'ldd' on it then it won't list any dynamic shared libraries, or if you run "readelf | grep NEEDED" on it then it won't come back with anything).

So then I'll have an MSB executable for my Dynamo program which doesn't link with any dynamic shared libraries. But of course, I can't run an MSB executable on my Raspberry Pi.

So here's the last thing I do:

Step 1) Edit the first 5 bytes in the ELF header of my Dynamo binary to change it from MSB to LSB

If I were to then run my Dynamo binary, it would of course crash because all the memory locations are in Big Endian instead of Little Endian, and so it will segfault. And so that's why I move on to step 2:

Step 2) Use 'readelf' on my binary to find the entry point: "readelf -h dynamo | grep Entry", and then at that address insert one instruction "setend be" so that the remainder of the code will be executed with the CPU in Big Endian mode

So then my program will run in Big Endian mode (even though the statically-linked executable file might be 100 megabytes instead of 5 megabytes).

Will this be possible?

Richard Kettlewell

unread,
Jan 20, 2022, 4:37:05 AM1/20/22
to
Frederick Gotham <cauldwel...@gmail.com> writes:
> So here's the last thing I do:
>
> Step 1) Edit the first 5 bytes in the ELF header of my Dynamo binary
> to change it from MSB to LSB
>
> If I were to then run my Dynamo binary, it would of course crash
> because all the memory locations are in Big Endian instead of Little
> Endian, and so it will segfault. And so that's why I move on to step
> 2:
>
> Step 2) Use 'readelf' on my binary to find the entry point: "readelf
> -h dynamo | grep Entry", and then at that address insert one
> instruction "setend be" so that the remainder of the code will be
> executed with the CPU in Big Endian mode
>
> So then my program will run in Big Endian mode (even though the
> statically-linked executable file might be 100 megabytes instead of 5
> megabytes).
>
> Will this be possible?

I don’t think the above will work. It will fail the first time that the
kernel and application disagree about the endianness of data in the
application’s memory.

For this kind of thing to actually work, the application would have to
be marked as MSB and the kernel needs to notice that and swap any
affected data on the way in and out. As far as I can see from a cursory
look, has not been done in Linux.

Any application that depended on communication in native endianness with
other applications would also fail. Obviously that’s very dependent on
what the application does.

--
https://www.greenend.org.uk/rjk/

Rainer Weikusat

unread,
Jan 20, 2022, 11:40:57 AM1/20/22
to
Frederick Gotham <cauldwel...@gmail.com> writes:
> I posted this post this morning to the forums for Raspberry Pi and
> wxWidgets. I'd also like to get opinions here.

[running program compiled for big endian on Raspberry Pi]

I think you'll need a BE operating environment for that. In principle,
you can create one using a suitable cross-compiler in a little-endian
environment.

Frederick Gotham

unread,
Jan 20, 2022, 4:45:51 PM1/20/22
to
On Thursday, January 20, 2022 at 4:40:57 PM UTC, Rainer Weikusat wrote:
> Frederick Gotham writes:
> > I posted this post this morning to the forums for Raspberry Pi and
> > wxWidgets. I'd also like to get opinions here.
> [running program compiled for big endian on Raspberry Pi]
>
> I think you'll need a BE operating environment for that. In principle,
> you can create one using a suitable cross-compiler in a little-endian
> environment.


I can't find a Linux distro for the "arm32 be8" platform anywhere. So do I need to use my x86_64 desktop PC to build 'buildroot' for arm32 be8, and then once I can boot up into a shell, install everything from source? Install GNOME and all the rest?

Rainer Weikusat

unread,
Jan 21, 2022, 12:00:01 PM1/21/22
to
For instance. Or install everything from adapted sources, eg, Debian
source packages.

NB: Building these won't necessarily be easier than using the upstream
sources themselves. It can as well be more complicated, because fewer
people build these and "builds on machine of maintainer" (but not
anywhere else) effects may be more frequently because of this.
0 new messages