-fpic and _syscall?() stuff in include/asm-i386/unistd.h

Chris Clark (chrisc@caldera.com)
27 Nov 1997 01:55:00 -0000


Here are some questions for those of you who are familiar with the
_syscall?() macros in include/asm-i386/unistd.h (and I'm talking
specifically about kernel v2.0.32, not 2.1.x, though I suspect the
problem is the same in the 2.1.x code).

Background:
---------------

I've noticed that any function defined in terms of these _syscall?()
macros will not compile (with gcc 2.7.2.1) to position-independent
code (i.e. with -fpic). This appears to be due to the fact that gcc
reserves the ebx register for it's own use when -fpic is in effect,
and the _syscall?() macros themselves try to use ebx directly in the
"input" part of the __asm__ statement. This causes the compiler to
complain about a "spilled" register.

This means any code that goes in a shared library can't use the
_syscall?() macros, because shared library code must be compiled with
-fpic.

For my own use (and the use of my friends :-) ), I've developed
alternate implementations of the _syscall?() macros which work even
when -fpic is active. My implementation uses a tad more explicit
assembly code to preserve the necessary registers, and doesn't make
such heavy use of the __asm__ "input-arg" facility. But it seems to
me that the macros in include/asm-i386/unistd.h ought to be "fixed" to
work for position-independent code. A desirable side-effect of
"fixing" unistd.h is that folks won't have to re-invent their own
local solutions to the problem just because they're compiling to
position-independent code.

My questions are these:
-------------------------

-- Is anyone (besides me) using the _syscall?() macros? If so, for
what?

-- Does anyone care that the _syscall?() macros lose when generating
position-independent code? Is there a known way to make the
_syscall?() macros work for -fpic? (in other words, "Am I merely
doing something stupid?")

-- Does anyone have opinions about the "right" way to fix them for
-fpic? (presuming we agree that they need to be "fixed" in the
first place, of course.) (I have my own solution, but I'm
interested to hear what others think is the "right" approach.)

Thanks,
Chris