Skip to content
Snippets Groups Projects
  1. May 31, 2013
  2. May 30, 2013
  3. May 29, 2013
    • Nadav Har'El's avatar
      Don't abort on unknown sysconf. · 05c34106
      Nadav Har'El authored
      Don't abort on an unimplemented sysconf parameter. One of the documented
      functions of sysconf(3) is to "test ... whether certain options are
      supported", so programs are free to test for features we don't support
      yet, and we're supposed to return -1 with errno set to EINVAL.
      
      For example, Boost tested _SC_THREAD_SAFE_FUNCTIONS which we didn't
      support. It would have been fine if we set EINVAL (it would switch
      from *_r functions to the non-reenatrant ones) - but it wasn't fine
      that we abort()ed because of this test :-)
      
      To be on the safe side, this patch still prints a message if we see an
      unknown sysconf - in case in the future we'll come across a new one we
      must treat. But eventually, the message should go away too.
      05c34106
    • Nadav Har'El's avatar
      Implement _SC_THREAD_SAFE_FUNCTIONS sysconf · a25cb86b
      Nadav Har'El authored
      Implement the _SC_THREAD_SAFE_FUNCTIONS sysconf, returning 1.
      
      _SC_THREAD_SAFE_FUNCTIONS is defined in Posix 1003.1c ("posix threads"),
      and is supposed to return 1 if the thread-safe functions option is
      supported (*_r() functions). Since we do implement those, we should return
      1 for this sysconf.
      
      Boost's system library uses this sysconf, and if it sees it is not
      available, restorts to the _r()-less variants, for no good reason.
      a25cb86b
    • Nadav Har'El's avatar
      Implement missing readdir64() as alias to readdir() · 61e295f2
      Nadav Har'El authored
      This patch implements readdir64, as an alias to readdir. We can do this,
      because on 64-bit Linux, even the ordinary struct dirent uses 64-bit
      sizes, so the structures are identical.
      
      The reason we didn't miss this function earlier is that reasonable
      applications prefer to use readdir64_r, not readdir64. Because Boost
      filesystem library thought we don't have the former (see next patch
      for fixing this), it used the latter.
      61e295f2
    • Nadav Har'El's avatar
      Say we also implement librt.so.1. · 737f83e9
      Nadav Har'El authored
      Say we also implement librt.so.1. This is required, for example, by the
      Boost libraries (e.g., libboost_system-mt.so.1.50.0). The librt library
      isn't actually a separate library on modern Linux - rather all its
      traditional functions are now in glibc, and "librt" is merely a filter
      on glibc. So no reason not to say we support librt too.
      
      Not to mention that we already implement a bunch of functions that
      traditionally resided in librt (nanosleep, sched_yield, sem_*, etc.
      737f83e9
    • Nadav Har'El's avatar
      Add simple readdir() test · 1f6cbdd3
      Nadav Har'El authored
      Added a simple readdir() and readdir_r() test.
      The test is successful - it turns out readdir() had no bug, and the bug
      was in mkbootfs.py, but since I already wrote the test I guess might as
      well add it.
      1f6cbdd3
  4. May 28, 2013
    • Nadav Har'El's avatar
      Fix getsockname() failure · 98a1fd2b
      Nadav Har'El authored
      getsockname() used to fail because by the time the call chain reached
      kern_getsockname() it got addrlen=0. The problem is getsockname1()
      which gives it an initialized local variable instead of the given
      addrlen.
      
      Most of these layers and copies are redundant, and are only left because
      of previous incarnations of the code which had copies from user space -
      but we need to at least get the unnecessary copies right ;-)
      98a1fd2b
    • Nadav Har'El's avatar
      Overhaul java.so command line · 31681180
      Nadav Har'El authored
      Java.so used to correctly support the "-jar" option, but did not fully
      allow the other "mode" of running Java: specifying a class name which is
      supposed to be searched in the class path. The biggest problem was that
      it only know to find class files, but not a class inside a jar in the class
      path - even if the classpath was correctly set.
      
      Unfortunately, fixing this C code was impossible, as JNI's FindClass()
      simply doesn't know to look in Jars.
      
      So this patch overhauls java.so: Java.so now only runs a fixed class,
      /java/RunJava.class. This class, in turn, is the one that parses the
      command line arguments, sets the class path, finds the jar or class to
      run, etc.. The code is now much easier to understand, and actually works
      as expected :-) It also fixes the bug we had with SpecJVM2008's "compiler.*"
      benchmarks, which forced us to tweak the class path manually.
      
      The new code supports running a class from the classpath, and also the
      "-classpath" option to set the class path. Like the "java" command line
      tool in Linux, this one also recognizes wildcard classpaths. For example,
      to run Jetty, whose code is in a dozen jars in /jetty, one can do:
      
              run.py -e "java.so -classpath /jetty/* org.eclipse.jetty.xml.XmlConfiguration jetty.xml"
      31681180
Loading