[cfe-dev] linking with libclang for ios
Anton Smirnov
dev at antonsmirnov.name
Fri Jul 11 23:26:13 PDT 2014
Anyone?
2014-07-08 14:39 GMT+06:00 Anton Smirnov <dev at antonsmirnov.name>:
> Hi.
>
> 2014-07-08 14:02 GMT+06:00 Alp Toker <alp at nuanti.com>:
>
>
>> On 08/07/2014 09:40, Anton Smirnov wrote:
>>
>>> I was said that `stat` is not supported on iOS:
>>> https://devforums.apple.com/message/1000186#1000186
>>>
>>> Any suggestion for replacement/walk-around?
>>>
>>
>> OK, that was my initial assumption. clang-interpreter is still the best
>> sample to get working..
>>
>
> I will definitely try clang-interpreter a bit later (for my second task -
> interpreting code), after i get syntax highlighting via Clang API at least.
>
>
>>
>> I've run a dtrace and unfortunately there are lots of stats, with most
>> looking redundant or even silly ("<stdin>"). Each needs to be investigated
>> individually (making stat() a no-op doesn't help) so this is some work --
>> best you can do is file a PR.
>
>
>> If you really want to get it working locally I think the best you can do
>> is set a breakpoint and try to hack away the callers.
>
>
> Sure, i will start from modifying Path.inc to make it working on iOS.
> Unfortunately i'm not good at c/objective-c at this time so any
> help is appreciated.
>
>
>> But for upstream we're going to need to fix this properly and it's not
>> really on the roadmap right now.
>>
>
> Totally agree with you.
>
> One more general question - Is there any way to check if all required
> system calls are present in ios libs?
>
>
>>
>> Alp.
>>
>>
>>
>>
>>>
>>> 2014-07-07 15:28 GMT+06:00 Anton Smirnov <dev at antonsmirnov.name <mailto:
>>> dev at antonsmirnov.name>>:
>>>
>>>
>>> Hey.
>>>
>>> 2014-07-07 14:39 GMT+06:00 Alp Toker <alp at nuanti.com
>>> <mailto:alp at nuanti.com>>:
>>>
>>>
>>>
>>> On 07/07/2014 11:14, Anton Smirnov wrote:
>>>
>>> Hi, Alp.
>>>
>>> 2014-07-07 12:52 GMT+06:00 Alp Toker <alp at nuanti.com
>>> <mailto:alp at nuanti.com> <mailto:alp at nuanti.com
>>>
>>> <mailto: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?
>>>
>>>
>>> This is a standard iOS platform? Try configuring with
>>> -mios-simulator-version-min=7.1
>>>
>>>
>>> Yes, it's standard iOS Platform (iOS Simulator). I've tried 7.0,
>>> does it make sense?
>>> I've found few similar issue reports but they relate to 3/4 xcode
>>> vrsion and pretty ancient ios versions.
>>>
>>>
>>>
>>>
>>> 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.
>>>
>>>
>>> Curious, what do you need the modifications for?
>>>
>>>
>>> Cling requires modified LLVM/Clang and it has it's own LLVM/Clang
>>> repos.
>>> I will start trying your clang-interpreter first which seems to do
>>> pretty the same.
>>>
>>>
>>> (Unless it's synced up to LLVM SVN very recently it'll be
>>> missing the fixes from this discussion.)
>>>
>>>
>>>
>>>
>>> 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.
>>>
>>>
>>> Okay, should work fine if you need file access. Try the
>>> configure switch I suggested.
>>>
>>>
>>>
>>>
>>> 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"?
>>>
>>>
>>> Sure, just run:
>>>
>>> ./clang-interpreter hello.cpp
>>>
>>> It mostly accepts the same arguments as normal clang.
>>>
>>>
>>> Good, i will give it a try.
>>>
>>>
>>> Alp.
>>>
>>>
>>> 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>
>>> <mailto:dev at antonsmirnov.name <mailto:dev at antonsmirnov.name>
>>> >
>>> <mailto:dev at antonsmirnov.name
>>> <mailto:dev at antonsmirnov.name>
>>> <mailto: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>
>>> <mailto:alp at nuanti.com <mailto:alp at nuanti.com>>
>>> <mailto:alp at nuanti.com <mailto:alp at nuanti.com>
>>> <mailto: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>>
>>> <mailto:dev at antonsmirnov.name <mailto:dev at antonsmirnov.name>
>>> <mailto:dev at antonsmirnov.name
>>> <mailto:dev at antonsmirnov.name>>>
>>> <mailto:dev at antonsmirnov.name
>>> <mailto:dev at antonsmirnov.name>
>>> <mailto:dev at antonsmirnov.name
>>> <mailto:dev at antonsmirnov.name>>
>>>
>>> <mailto: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>
>>> <mailto:cfe-dev at cs.uiuc.edu <mailto:cfe-dev at cs.uiuc.edu>>
>>> <mailto:cfe-dev at cs.uiuc.edu
>>> <mailto:cfe-dev at cs.uiuc.edu> <mailto: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
>>>
>>>
>>>
>>> -- 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/20140712/6eb799b1/attachment.html>
More information about the cfe-dev
mailing list