Re: Runnig solaris binary(32 bit) on linux(64 bit)

[Warner Losh <imp@bsdimp.com>]

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

On Thu, Feb 16, 2023 at 12:40 PM David Woodhouse <dwmw2@infradead.org>
wrote:

> On Thu, 2023-02-16 at 09:29 -1000, Richard Henderson wrote:
> > On 2/16/23 09:02, David Woodhouse wrote:
> > > It wouldn't be beyond the wit of man to extend qemu-user to support the
> > > similar personality variations for SCO/Solaris/etc. using that as a
> > > guide.
> >
> > Not beyond wit but perhaps beyond patience.
> >
> > It would certainly be possible to emulate the "easy middle" of one POSIX
> guest on a
> > different POSIX host.  But the dusty corners are going to get in the
> way, where we
> > currently rely on guest and host having identical semantics, and pass
> the system call
> > through to the host.
> >
> > It's a big job.
>
> True, but the existing iBCS / linux-abi kernel patches should highlight
> a lot of those dusty corners.
>

So one thing to understand, the iBCS is a separate ABI. This means that
you'd
have to rewrite everything from the syscall dispatch on down. Even if this
were
relevant, it would be a huge job.

A lot would depend on how much of Solaris is used. Solaris is ELF, which is
good
(it would be even worse if it were SunOS 4, then it's a.out and a whole lot
of other
complication that's more of a bsd-user thing). However, as others have
pointed
out, linux-user assumes a linux kernel. While one can run linux-user on
FreeBSD
with its Linux ABI implementation, even that's quite limited in what it can
do (I
needed to do this for some kexec support I was adding to FreeBSD boot loader
that ran as a Linux binary). I had to make tweaks to FreeBSD's emulation
to make it work, and that was for a binary that used only 10 system calls,
no
threads, no signals, nothing "messy" and apart from some extensions to
64-bits,
nothing that wasn't in 7th Edition Unix.

And there's also a number of special filesystems, IIRC, on Solaris that are
used
like linux's /sys and /proc filesystems, but with different details. And a
million other
details. Knowing the details isn't enough, assuming you could know them from
cribbing from existing code. You have to actually go implement the details
and
that would be a very tedious job. Even if you kept it to a subset that your
program
uses...

I started on a Venix emulator (ancient Unix V7 port to 8088/8086 micros I
cut my
teeth on), and even that was daunting. Now, with 3 years of bsd-user
hacking and
upstreaming under my belt, it would be easier, but there's a *HUGE*
learning curve
to understand the CPU, its exception model, how system calls are handled,
how
memory is mapped, etc. And the 'assume we're on linux' is definitely
leveraged
for memory mapping in the existing linux-user code if you were to copy it
all
as a starting point.

When people say it's a big job, they are underselling it somewhat. It would
be
a big job for the maintainers of linux-user who have all the context and
know
where the gotchas are. For anybody else, learning everything you need to
know itself is a big job.

Your best bet is qemu-sparc-system + Solaris install.

Warner

P.S. Sorry to go into partial rant mode, but 4 years ago when I started
helping
the folks working with bsd-user, I thought how hard could it be... now I
know...

[-- Attachment #2: Type: text/html, Size: 4867 bytes --]