[cfe-dev] linking with libclang for ios
Anton Smirnov
dev at antonsmirnov.name
Tue Jul 8 01:39:52 PDT 2014
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/20140708/bec26867/attachment.html>
More information about the cfe-dev
mailing list