Path: utzoo!attcan!uunet!world!madd
From: madd@world.std.com (jim frost)
Newsgroups: comp.unix.aix
Subject: Re: syscall() in AIX 3.1
Message-ID: <1990Sep14.183315.23673@world.std.com>
Date: 14 Sep 90 18:33:15 GMT
References: <301@bksmel.oz.au>
Organization: Saber Software
Lines: 38

paulf@bksmel.oz.au (Paul Fitchett) writes:
[...]
>The code has a few calls to syscall()
[...]

>No worries, says I, I'll just extract read.o from libc.a, change the symbols
>in it to rEad and replace the syscall(...) with rEad(fd, buf, nbytes). That'll
>do for now...
>However, there is no read.o in libc.a. Instead there is a monster called shr.o
>which appears to have everything in it, some sort of shared object.
>I tried the above approach but couldn't get it to work wih shr.o as an ordinary
>object in the compile or as part of some local library, (libfoo.a ;-)

>So, if anyone could offer some advice on how to handle syscall (by any means at
>all) in AIX3.1 I would be very grateful.

"Good luck."  The RS/6000 does not use conventional techniques for
making system calls.  What happens (or appears to happen -- this
information was gleaned from disassembling library routines) is r2
(usually the TOC pointer) is loaded with the syscall number and a
branch is made to 0x2020.  The documentation I have suggests that the
syscall numbers and even the branch can be changed (ie it's not
fixed), so it will be fairly hard to implement syscall some other way.

The .o you ran across should be called shr.o; one exists for each of
the major shared libraries instead of a lot of small .o files.  Given
the way linking is done it would be a lot more efficient to have a
single .o, and on the RS/6000 they spent a lot of effort making
run-time linkage efficient.  I suggest reading the Jan 1990 `IBM
Journal of Research and Development' for some information on how
linkage and system calls are done.

The short answer is that I think it'll be a bitch to port that
program.

jim frost
saber software
jimf@saber.com