[llvm] r333147 - [ORC] Add findSymbolIn() wrapper to C bindings.

[Andres Freund via llvm-commits]

Hi,

On 2018-05-24 01:01:42 -0000, Andres Freund via llvm-commits wrote:
> Author: anarazel
> Date: Wed May 23 18:01:42 2018
> New Revision: 333147
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=333147&view=rev
> Log:
> [ORC] Add findSymbolIn() wrapper to C bindings.
> 
> In many cases JIT users will know in which module a symbol
> resides. Avoiding to search other modules can be more efficient. It
> also allows to handle duplicate symbol names between modules.
> 
> Reviewed By: lhames
> 
> Differential Revision: https://reviews.llvm.org/D44889
> 
> Modified:
>     llvm/trunk/include/llvm-c/OrcBindings.h
>     llvm/trunk/lib/ExecutionEngine/Orc/OrcCBindings.cpp
>     llvm/trunk/lib/ExecutionEngine/Orc/OrcCBindingsStack.h
>     llvm/trunk/unittests/ExecutionEngine/Orc/OrcCAPITest.cpp

This unfortunately failed on the OSX builders:
http://green.lab.llvm.org/green/job/clang-stage1-cmake-RA-incremental/48851/
but not on others:
http://lab.llvm.org:8011/builders/clang-cmake-aarch64-global-isel/builds/5739
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-debian-fast/builds/8926/steps/test/logs/stdio
...

The green.lab.llvm.org builder seems to be OSX - I can't for the heck of
me see what was OS specific in that change however.

I've organized remote access to an OSX laptop (using linux myself), and
will build LLVM there to see whether I can reproduce the problem. On
linux the tests pass, even under valgrind.

I'm fairly new to working on LLVM, so I'm not precisely sure how
aggressively changes breaking the build are reverted, especially if it's
just on some platforms?  The docs don't say anything more specific than
"You are expected to check the build bot messages to see if they are
your fault and, if so, fix the breakage." - which doesn't quite address
that...

Regards,

Andres