paulf@bksmel.oz.au (Paul Fitchett) (09/04/90)
Hello, I'm having a problem porting some software from a Sun to an RS6000 running AIX 3.1. The code has a few calls to syscall() e.g. . . int fd; char *buf; int nbytes; . . syscall(SYS_read, fd, buf, nbytes); . . My trusty AIX porting guide says that.. "The following functions are found on standard 4.3 BSD systems, but are not on AIXv3.1: ..., 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. Thanks, Paul Fitchett. (paulf@bksmel.oz.au) P.S. The above may sound like a tyro at play, I will admit, so advice to RTFM will be accepted if a reference is given. :-) +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
madd@world.std.com (jim frost) (09/15/90)
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