1. 31 Mar, 2017 4 commits
  2. 15 Mar, 2017 4 commits
  3. 14 Mar, 2017 3 commits
  4. 24 Jan, 2017 7 commits
    • David Gibson's avatar
      .travis.yml: Add clang builds to trusty · 1a2cc003
      David Gibson authored
      This enables clang compiler builds for the trusty Travis environment.
      Signed-off-by: default avatarDavid Gibson <david@gibson.dropbear.id.au>
      1a2cc003
    • David Gibson's avatar
      coroutine: Stack allocation · b4f0767d
      David Gibson authored
      At present, coroutine stacks must be allocated explicitly by the user,
      then initialized with coroutine_stack_init().  This adds a new
      coroutine_stack_alloc() function which allocates a stack, making life
      easier for users.  coroutine_stack_release() will automatically determine
      if the given stack was set up with _init() or alloc() and act
      accordingly.
      
      The stacks are allocate with mmap() rather than a plain malloc(), and a
      guard page is added, so an overflow of the stack should result in a
      relatively debuggable SEGV instead of random data corruption.
      Signed-off-by: default avatarDavid Gibson <david@gibson.dropbear.id.au>
      b4f0767d
    • David Gibson's avatar
      coroutine: Enable valgrind · fe3995b4
      David Gibson authored
      Currently valgrind checks are disabled on the coroutine module,
      because switching stacks tends to confuse it.  We can work around this
      by using the valgrind client interface to explicitly inform it about
      the stacks we create.
      Signed-off-by: default avatarDavid Gibson <david@gibson.dropbear.id.au>
      fe3995b4
    • David Gibson's avatar
      coroutine: Remove on-stack buffers from testcases · f6557ca6
      David Gibson authored
      In preparation for enabling valgrind tests, remove instances where we
      allocate a coroutine's stack from a buffer itself on the stack.  Not all
      that surprisingly, valgrind gets very, very confused by having one
      "thread"'s stack embedded within another's.
      Signed-off-by: default avatarDavid Gibson <david@gibson.dropbear.id.au>
      f6557ca6
    • David Gibson's avatar
      coroutine: Move total initialization outside coroutine · d24c5a01
      David Gibson authored
      The sample coroutine in api-3 initializes a total to 0, then adds up the
      pseudo-random data it has placed into a stack buffer, to ensure that the
      compiler won't elide the reading and writing of that buffer.  After the
      coroutine has completed, we verify that total is non-zero so that we'll
      detect if the coroutine failed to execute entirely.
      
      Except that the initialization of total is within the coroutine itself,
      so it could also be non-zero due to it simply being uninitialized.  This
      moves the initialization outside the coroutine, to make the test a little
      more robust.
      Signed-off-by: default avatarDavid Gibson <david@gibson.dropbear.id.au>
      d24c5a01
    • David Gibson's avatar
      coroutine: Remove problematic diagnostic from api-3 test · ace6131e
      David Gibson authored
      The api-3 testcase devotes most of its available stack space to a test
      buffer, leaving only a small amount (COROUTINE_MIN_STKSZ) for the actual
      stack usage of the coroutine.
      
      It turns out that the ccan/tap diag() function can - depending on compiler
      version and flags, and on whether diagnostics are enabled - exceed that
      limited stack space.  That leads to a stack overrun, and in turn corruption
      of the parent routine's stack, generating unpredictable and hard to debug
      SEGVs.
      
      At present, this bug seems to be tripped by clang-3.8 when diagnostic
      messages are printed.
      
      This removes the troublesome diag() call.
      Signed-off-by: default avatarDavid Gibson <david@gibson.dropbear.id.au>
      ace6131e
    • Rusty Russell's avatar
      tal: make tal_len/tal_count(NULL) return 0. · 9b3f4ef6
      Rusty Russell authored
      Previously it crashed, but if you're always dealing with tal arrays,
      this is painful.
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      9b3f4ef6
  5. 19 Jan, 2017 1 commit
  6. 18 Jan, 2017 3 commits
    • David Gibson's avatar
      ccanlint: Correct default coverage tool for clang · 319dadd4
      David Gibson authored
      Currently ccanlint defaults to using "gcov" as the coverage analysis tool
      for any compiler defining __GNUC__.  That's generally correct for the
      (system default) gcc.  However, clang also defines __GNUC__ because it
      implements the GCC langauge extensions.  For clang, "gcov" is not the
      correct coverage tool (clang does use roughly the gcov format, but unless
      you're very lucky the system gcc and system clang won't use the same gcov
      versions).
      
      This changes the default coverage tool in the case of clang to the correct
      "llvm-cov gcov".
      Signed-off-by: default avatarDavid Gibson <david@gibson.dropbear.id.au>
      319dadd4
    • David Gibson's avatar
      ccanlint: Allow path to gcov to be overriden · d1827b42
      David Gibson authored
      Currently ccanlint always assumes that the coverage tool can be
      invoked under the command "gcov".
      
      However, the coverage tool generally needs to be closely matched to
      the compiler version.  So, the current behaviour won't work with
      compilers other than gcc, like clang.  It won't even work for a gcc
      version which isn't the standard system one matching gcov.
      
      To address this, allow the command for the coverage tool to be
      overridden on the ccanlint command line with a new --gcov option.  We
      also allow it to be overridden for make check with a GCOV make
      variable.
      Signed-off-by: default avatarDavid Gibson <david@gibson.dropbear.id.au>
      d1827b42
    • David Gibson's avatar
      tools: Consolidate gcov handling · bcb956d9
      David Gibson authored
      At the moment, invocation of the 'gcov' tool for coverage analysis
      from ccanlint is put directly into the tests_compile_coverage.c and
      tests_coverage.c files.  This makes it awkard to extend.
      
      So, this patch moves the invocation of gcov into a new tools/gcov.v
      file, analagous to tools/compile.c.
      Signed-off-by: default avatarDavid Gibson <david@gibson.dropbear.id.au>
      bcb956d9
  7. 17 Jan, 2017 3 commits
    • David Gibson's avatar
      .travis.yml: Add valgrind testing · 0fd6bb10
      David Gibson authored
      Currently, our Travis builds don't have valgrind installed, meaning
      that ccanlint's valgrind based tests will be skipped, which is
      unfortunate.
      
      This adds valgrind to some of the builds to give us better CI
      coverage.  It's not added for Precise with gcc, because that causes
      failures which appear to be due to something in the builtins of that
      gcc version.
      Signed-off-by: default avatarDavid Gibson <david@gibson.dropbear.id.au>
      0fd6bb10
    • David Gibson's avatar
      .travis.yml: Add builds under Ubuntu Trusty · 870b6316
      David Gibson authored
      At the moment our Travis builds all use Travis's default Ubuntu
      Precise base distro.  For wider testing, add a build using their
      Ubuntu Trusty distro.  Only build with gcc there, for now, since clang
      will cause ccanlint failures, due to the gcov version there not being
      suitable for clang output.
      Signed-off-by: default avatarDavid Gibson <david@gibson.dropbear.id.au>
      870b6316
    • David Gibson's avatar
      .travis.yml: Rework Travis matrix · 813e9726
      David Gibson authored
      At the moment the .travis.yml implicitly constructs a build matrix
      with the two compiler options.  In future we want to add more build
      options for wider testing: different base distro, more compiler
      versions, etc.  However, a fair few of the possible combinations have
      various problems meaning we don't want to test them routinely.
      
      So, this reworks from implicitly constructing the matrix to using
      matrix: include: options to explicitly build the options we want.
      Signed-off-by: default avatarDavid Gibson <david@gibson.dropbear.id.au>
      813e9726
  8. 13 Jan, 2017 1 commit
  9. 11 Jan, 2017 1 commit
  10. 09 Jan, 2017 5 commits
  11. 07 Jan, 2017 1 commit
  12. 29 Dec, 2016 5 commits
  13. 24 Dec, 2016 2 commits
    • David Gibson's avatar
      ccanlint: Move ccanlint test options from _info comments to code · 0fe2d094
      David Gibson authored
      Currently, _info files can specify options, or note expected failures, for
      ccanlint checks in the _info file with specially structured comments. That
      differs from most other things ccanlint gets from _info, where it instead
      executes the info file with certain parameters.
      
      This changes ccanlint and existing _info files to use the normal method for
      the ccanlint test options as well.  This also has the advantage that an
      info file can alter its test options based on things from config.h - in
      some cases whether a test can work or not might depend on various things.
      Signed-off-by: default avatarDavid Gibson <david@gibson.dropbear.id.au>
      0fe2d094
    • David Gibson's avatar
      Makefile: Make module checks depend on info file · 25b7406d
      David Gibson authored
      Changing the _info file can change how ccanlint assesses the module.
      Therefore, if the _info file changes, we should re-run ccanlint module
      tests with make check.  We didn't previously have a dependency for that,
      though, so this adds it.
      Signed-off-by: default avatarDavid Gibson <david@gibson.dropbear.id.au>
      25b7406d