Getting the linker to resolve system calls and other questions...

Getting the linker to resolve system calls and other questions...

Post by Michael T. Peterso » Thu, 24 Aug 1995 04:00:00

In order to implement thread-blocking I/O I have to write my own wrapper
services and I'm not sure what is the best way to proceed.

I've been doing some experimenting and here's what I've come up with:

In pthread_io.c I have the following declaration:

   static inline
   _syscall2(long,socketcall,int,call,unsigned long *, args );

Followed by a bunch of functions of which the following, syscall_accept(), is a
typical example:

   static int
   syscall_accept( int fd, struct sockaddr *addr, int *addrlen )
      int ret;
      unsigned long args[3];

       * Init the args and call the kernel.
      args[0] = (unsigned long) fd;
      args[1] = (unsigned long) addr;
      args[2] = (unsigned long) addrlen;

      pthread_mutex_lock( &syscall_lock );
      ret = socketcall( SYS_ACCEPT, args );
      pthread_mutex_unlock( &syscall_lock );

       * If the call failed because of a signal, then continue to retry until
       * we succeed or fail for some other reason.  NB: Later on we'll
       * integrate this in with the per-thread signal facility and do this
       * correctly.  For now, just restart it.
      while( ret < OK )
          if( ret != -EINTR )

          pthread_mutex_lock( &syscall_lock );
          ret = socketcall( SYS_ACCEPT, args );
          pthread_mutex_unlock( &syscall_lock );

      return( ret );

What I found was that when I try to link a test program with this module
(containing these wrapper functions), linker can not find the socketcall() entry
point unless I include the _syscall2(...) declaration!

First, can someone explain to me what's going on?  Is this _syscall2() some kind
of magic macro?  I happened upon this strategy by browsing thru the ./sysdeps
directory in the libgcc library sources and this is almost exactly what is
done there, albeit I don't understand why.

Second, do I really need to serialize the process's calls to system services?
Off the top of my head, I don't see why this is necessary, but I've got the
locks in place just in case someone tells me that Linux's kernel is
partially preemptible.

Finally, the global lock notwithstanding, is this really the best way to write
wrappers that call system services?  Any advice, suggestions, pointers would be
very welcome


   |   Michael T. Peterson     | The hell you say.  My opinions are my own |
   | | and worth every damn cent you paid.       |


1. xlC - linker error: unresolved system call BUT it is in libc


I have a problem trying to use the system call getprocs().  There is no
declaration of this anywhere in /usr/include although the header file
procinfo.h is present with declarations for the data structures passed
as parameters to getprocs.  I have tried declaring getprocs as extern in
my source which gets past the compiler but the linker gives the error:

ld: 0711-317 ERROR: Undefined symbol:

nm of libc.a gives the following references to getprocs:

getprocs             d     276512       4
getprocs             U          -
.getprocs            T    1219264
.getprocs            t    1219264      40

Can anyone help please.


2. Help: Winnt+Win95+Linux triple boot!!!

3. Help on resolving orphaned processes caused by system() call

4. Can U install Red Hat 6rpm's in Red 7.1 ?

5. How I could add a new system call to linux or modify a system calls

6. The Free software Bazaar needs developers.

7. How to use open system call in a new system call

8. FA: Lot vintage hard drives mfm,scsi(Seagate/Rodime/Tandon)

9. "Interrupted system call" at "low level" - system calls

10. libf2c.a linker resolve problem

11. Linker doesn't resolve symbol - what's wrong?

12. Dynamic linker resolving to wrong symbols

13. gethostbyname() DNS resolves for some apps, not for others