This is the mail archive of the libc-hacker@sourceware.cygnus.com mailing list for the glibc project.

Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: syscalls.list changes: List arguments


Andreas Jaeger <aj@suse.de> writes:

> Your notation is something like "i:spi" where the argument before the
> colon is the return type (seems to be required) and the rest are the
> arguments.  

Yes, return type is required and you'll see why below.

> - "i" can be an integer of any size - the important information is
>   here that it is *not* a pointer.  Is this right?

We need to explicitly denote integers larger than int.  "l" for long
and "L" for long long are reasonable choices.  I haven't done that
yet, but it needs to be done.  Here's an example to show how the
signatures are used:

Consider this line from sysdeps/unix/syscalls.list:

read		-	read		i:ipi	__libc_read	__read read

The presence of a signature containing a pointer key-letter (currently
"p" or "s") causes the script unix/make-syscalls.sh to generate a
thunk.  For read, this appears in BUILD_DIR/sysd-syscalls:

ifeq (,$(filter read,$(bp-thunks)))
bp-thunks += read
$(objpfx)$(bppfx)read.ob: $(common-objpfx)s-proto.d
	(echo '#include <bp-thunks.h>'; \
	 echo 'BP_THUNK_i_ipi (__libc_read)'; \
	 echo 'BP_ALIAS (__libc_read, __read)'; \
	 echo 'BP_ALIAS (__libc_read, read)'; \
	) | $(COMPILE.c) -x c -o $@ -
endif

This rule builds the file BP-read.ob (alongside read.ob which contains
the traditional system-call interface).  BP-read.ob defines
__BP___libc_read as well as its aliases __BP___read and __BP_read.

__BP___libc_read accepts bounded pointer args, strips the bounds
and calls the traditional simple-pointer interface __libc_read.
That code is defined in BP_THUNK_i_ipi, which is defined in
sysdeps/generic/bp-thunks.h:

#define BP_ALIAS(STRONG, ALIAS) weak_alias (__BP_##STRONG, __BP_##ALIAS)
...
#define PV(P) __ptrvalue (P)
...
#define voidp void *__bounded
#define charp char *__bounded
...
#define BP_THUNK_i_ipi(NAME) __unbounded { \
  extern int NAME (int, void *, int); \
  int __BP_##NAME (int i0, voidp p1, int i2) \
    { return NAME (i0, PV (p1), i2); } }

The thunk implementations in bp-thunks.h are incomplete because they
don't yet check bounds, they only strip away bounds in order to call
the real system-call.  I plan to add some new signature key letters to
facilitate bounds checking.  E.g. key-letter "b" will indicate a
buffer argument, and "n" will indicate an argument that gives its
required length.  The signatures for read(2) & write(2) will then
become "i:ibn" and BP_THUNK_i_ibn will contain code to check that
the bounds of the buffer argument are large enough to accommodate
the number of bytes indicated in the buffer-length argument.

> - Why are you differentiating between "s" and "p"?  Where are you
>   treating strings different than other pointers?

The intent is to check that chars at bytes 0..strlen (s)+1 fit within
the bounds of the pointer.  This is a dynamic check.  For other
pointers, we only need a static check that bytes 0..sizeof (*p) fit
within the bounds of the pointer.  That check isn't implemented yet.
Uli started writing some stuff to extract the type of "p" so we could
do that check.

> - Does it make sense to convert the remaining syscalls.list files?

Yes.  The whole thunk implementation is preliminary and subject to
change, but it is still useful to add signatures to all syscalls.list.

>   Not everything is changed so far.  Is it a problem if something
>   hasn't been converted for the bounded pointer case?

No, it's not a problem for the non-BP libs.  make-syscalls.sh
accepts either signatures or arg counts.  If a syscall has only
an old-style arg count, it means that no BP thunk will be defined,
but that's only a problem if the syscall has pointers in its
signature, and a BP program calls it.  In this case, the BP program
will get an undefined at link time.

> Could you please also document the notation for the arguments
> somewhere?

Yes, of course.

Greg

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]