[cfe-dev] linking with libclang for ios

Anton Smirnov dev at antonsmirnov.name
Mon Jul 7 01:14:19 PDT 2014


Hi, Alp.

2014-07-07 12:52 GMT+06:00 Alp Toker <alp at nuanti.com>:

>
> On 07/07/2014 09:24, Anton Smirnov wrote:
>
>> I've started to edit Mutex.cpp and RWMutex.cpp and found it's not used at
>> all if "LLVM_ENABLE_THREADS" was off during config.
>> So it seems that my issues was solved with it.
>>
>
> Great
>

Thanks for pointing me right direction ;)


>
>  Anyway i'm having another issue:
>>
>> *2014-07-07 12:19:54.090 LibClangUsage7Demo[64275:60b] started*
>>
>>
>> *Detected an attempt to call a symbol in system libraries that is not
>> present on the iPhone:*
>>
>> *stat$INODE64 called from function _ZN4llvm3sys2fs6statusERKNS_5TwineERNS1_11file_statusE
>> in image LibClangUsage7Demo.*
>>
>>
>> Is stat missing in ios simulator? It seems that i will have to fix such
>> issues one-by-one..
>>
>> Is there any ios-friendly version of llvm/clang? Is it ios simulator
>> limitations (systems calls to absent systems methods)?
>>
>
> The LLVM/clang codebase is meant to be portable..
>
> So, the OS filesystem symbols are available but not implemented on your
> platform:
>

What does it mean "available but not implemented"? I'm not sure i
understand it as i have no compile/link errors, runtime errors only.
Does it mean it has required functions declarations in headers while
compiling, symbols while linking but absent for some reason in runtime?
How can that be? i expect to have linker errors if required system calls
are absent.

I'm using xcode toolchain and sysroot to cross-compile for ios so i expect
it to have valid and actual headers and compiled systems libs.

What can i do to fix stat missing in llvm::sys::status(..) ? Any flags or
change invocation to any existing system method?


>
> That's good news because it means there's a good chance you can get your
> application working without porting LLVM's System module.
>

I'm afraid i will discover a lot of places with runtime errors (due to
missing system libs) ;(
Does anybody know any other expected missing/not implemented calls for ios?


>
> As I recall, you wanted to perform an in-memory compilation and produce
> LLVM IR, and I suggested using the clang-interpreter demo as a starting
> point.
>
>
At that point i'm just trying to have actual llvm/clang working via Clang-C
API. This means i don't have to have any major modifications, just
cross-compile with right configure params.

Probably the next step will be look into Cling modifications for LLVM/Clang
and making it working.



> Let's take that a little further..
>
> You'll need to modify the clang-interpreter sample so it loads C source
> code for the main file from memory instead of trying to read from the
> filesystem which apparently doesn't existing on your platform. The code you
> use shouldn't include any headers or that'll incur filesystem access.
>

Actually i can access files in ios app sandbox so i expect LLVM/Clang
working for files in it.


>
> Meanwhile I've added non-JIT interpreter support in clang r212083, and if
> that still doesn't work you can modify the sample to print IR to check if
> things work.
>

Great! How i can i try it? Any example to interpret "hello-world"?


>
> With some luck it won't attempt to read from the filesystem at all after
> that, so won't hit the missing OS features.
>
> If there are more errors, we'll need to refine the approach a little and
> eliminate other kinds of file accesses but that should be the general angle
> of attack.
>
> It sounds like a fun project, keep the list posted :-)
>

Well, yes it is. I'm just making proof of concept. Any help is appreciated.


>
> Alp.
>
>
>
Regards, Anton.


>
>
>
>> Thanks,
>> Anton.
>>
>>
>> 2014-07-06 17:16 GMT+06:00 Anton Smirnov <dev at antonsmirnov.name <mailto:
>> dev at antonsmirnov.name>>:
>>
>>
>>     I've just tried to rebuild libclang.a
>>     with -miphoneos-version-min=7.0 - no luck.
>>     Also i've removed --enable-optimized --disable-assertions
>>     configure flags and it confirmed error line (Mutex.cpp):
>>
>>     // Destroy the attributes
>>     errorcode = pthread_mutexattr_destroy(&attr);
>>
>>     Should setting LLVM_ENABLE_THREADS to "off" help?
>>
>>
>>
>>
>>     2014-07-06 12:03 GMT+06:00 Alp Toker <alp at nuanti.com
>>     <mailto:alp at nuanti.com>>:
>>
>>
>>         Did you try building with LLVM_ENABLE_THREADS off?
>>
>>         Also consider trying ToT to get the latest fixes.
>>
>>         Alp.
>>
>>
>>
>>         On 06/07/2014 08:23, Anton Smirnov wrote:
>>
>>             I've found Mutex.cpp file in llvm sources and it seems
>>             it's not the first mutex-related call in constructor.
>>             This makes me think it's really absent method in system libs:
>>
>>             // Construct a Mutex using pthread calls
>>
>>             MutexImpl::MutexImpl( bool recursive)
>>
>>               : data_(0)
>>
>>             {
>>
>>               // Declare the pthread_mutex data structures
>>
>>               pthread_mutex_t* mutex =
>>
>>             static_cast<pthread_mutex_t*>(malloc(sizeof(pthread_mutex_t)
>> ));
>>
>>               pthread_mutexattr_t attr;
>>
>>
>>               // Initialize the mutex attributes
>>
>>               int errorcode = pthread_mutexattr_init(&attr);
>>
>>               assert(errorcode == 0); (void)errorcode;
>>
>>
>>               // Initialize the mutex as a recursive mutex, if
>>             requested, or normal
>>
>>               // otherwise.
>>
>>               int kind = ( recursive  ? PTHREAD_MUTEX_RECURSIVE :
>>             PTHREAD_MUTEX_NORMAL );
>>
>>               errorcode = pthread_mutexattr_settype(&attr, kind);
>>
>>               assert(errorcode == 0);
>>
>>
>>             #if !defined(__FreeBSD__) && !defined(__OpenBSD__) &&
>>             !defined(__NetBSD__) && \
>>
>>                 !defined(__DragonFly__) && !defined(__Bitrig__)
>>
>>               // Make it a process local mutex
>>
>>               errorcode = pthread_mutexattr_setpshared(&attr,
>>             PTHREAD_PROCESS_PRIVATE);
>>
>>               assert(errorcode == 0);
>>
>>             #endif
>>
>>
>>               // Initialize the mutex
>>
>>               errorcode = pthread_mutex_init(mutex, &attr);
>>
>>               assert(errorcode == 0);
>>
>>
>>               // Destroy the attributes
>>
>>               errorcode = pthread_mutexattr_destroy(&attr); // fails here
>>
>>               assert(errorcode == 0);
>>
>>               // Assign the data member
>>               data_ = mutex;
>>
>>             }
>>
>>             I've marked where it fails.
>>             How can that be that previous mutex-related methods
>>             success and this one fails?
>>             What can i do to fix it?
>>
>>             Regards, Anton.
>>
>>
>>             2014-07-05 19:31 GMT+06:00 Anton Smirnov
>>             <dev at antonsmirnov.name <mailto:dev at antonsmirnov.name>
>>             <mailto:dev at antonsmirnov.name
>>
>>             <mailto:dev at antonsmirnov.name>>>:
>>
>>
>>                 Hi.
>>
>>                 I was able to cross-compile llvm/clang for i386 and
>>             i'm trying to
>>                 use it in my ios app.
>>                 Also i was able to add headers and static libs (both
>>             libLLVM*.a
>>                 and libclang*.a) and compile/link the project with no
>>             errors.
>>
>>                 But when trying to run simple app i'm getting error:
>>
>>                 *Detected an attempt to call a symbol in system
>>             libraries that is
>>                 not present on the iPhone:*
>>
>>                 *pthread_mutexattr_destroy$UNIX2003 called from function
>>                 _ZN4llvm3sys9MutexImplC2Eb in image LibClangUsageDemo3.*
>>
>>
>>
>>                 What can i do in order to fix it?
>>
>>                 Is it llvm/clang issue or i'm doing smth wrong?
>>
>>                 Regards, Anton.
>>
>>
>>
>>
>>             _______________________________________________
>>             cfe-dev mailing list
>>             cfe-dev at cs.uiuc.edu <mailto:cfe-dev at cs.uiuc.edu>
>>
>>             http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>>
>>         --         http://www.nuanti.com
>>         the browser experts
>>
>>
>>
>>
> --
> http://www.nuanti.com
> the browser experts
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140707/2b547221/attachment.html>


More information about the cfe-dev mailing list