Re: Can I run an application compiled with gcc ABI 2.95 on a kernel compiled with gcc ABI 3.4?

[Jamie Lokier <jamie@shareable.org>]

George G. Davis wrote:
> On Fri, May 15, 2009 at 02:55:57PM +0100, Ben Dooks wrote:
> > On Fri, May 15, 2009 at 02:51:05PM +0100, Jamie Lokier wrote:
> > > Eek, can you say a bit more about the ARM EABI mismatch?
> > > 
> > > I would like to run a shiny modern ARM EABI kernel and userspace, but
> > > also need to run one or two OABI binaries (from the gcc 2.95 era) on
> > > the same kernel which I cannot recompile because they're built with
> > > closed source libraries only supplied as OABI.
> > > 
> > > Does that not work at all?
> > 
> > There are a few ioctl() incompatibilities between the two ABIs, the
> > main problems are within the ALSA API. Mostly it will work, but there
> > are a couple of caveats.
> 
> Right, you can run ARM OABI binaries on an ARM eABI kernel by enabling
> OABI_COMPAT.  However, as Ben notes, there are (more than, IMNSHO ; )
> "a couple of caveats".  Most of the "easy" ABI compatibility fixups
> should be handled already via OABI_COMPAT.  However, it's practically
> impossible to fixup all OABI/eABI compatibility issues due to register
> assignment, parameter alignment and/or packing differences between
> the two ABIs.  You would have to analyze all kernel and driver
> user interfaces to reassign parameters to registers, align and/or
> repack data structures, etc.,.  In fact, some of the existing fixups
> include side effects that in some cases can cause userspace code to
> fail, depending on how it is using I/O parameters, e.g. in some cases,
> library code may try to validate parameters which are relocated and
> those tests fail due to reshuffling of parameters.  It's a nasty
> path to go down, quite frankly. I would not recommend trying to
> support OABI binaries on an eABI kernel using OABI_COMPAT.

Structure packing: Isn't that basically the same set of fixups that
need to be done for 32-bit compatibility on 64-bit kernels?  Could it
even use the same code - sneakily replacing "32" with OABI and "64"
with EABI?

Register/parameter assignment: How is that relevant to the kernel
interface, if the kernel itself and modules are all EABI?  The system
call interface is a fixed set of registers.

It sounds like you're saying I should use OABI kernels and userspace
even with latest kernels, if I have a single OABI binary that might
use anything interesting from the kernel, like readdir, poll, signal
context, ioctl, device read/write, or any other system calls which
take a struct that isn't all 32-bit words.

-- Jamie