[cfe-dev] libclang crash when parsing MS-style inline assembly

William Ledoux william.ledoux at gmail.com
Wed Oct 30 08:54:05 PDT 2013


Hi Chad,

Thanks, yes it makes perfect sense,
I guess it is one reason why clang is quite strict about inline asm (
http://clang.llvm.org/compatibility.html#inline-asm )

So now I understand that there is no way to parse MS-style inline assembly
without a target asm parser.
But I still need to figure out if I can and how to tell libclang to
initialize a specific target.



On Wed, Oct 30, 2013 at 4:27 PM, <mcrosier at codeaurora.org> wrote:

> Hi William,
> I can answer your second question.  GCC style inline assembly does not
> require a target AsmParser.  MS-style inline assembly requires a parser
> because this is how we discover the constraints.  Hope this helps.
>
>  Chad
>
> > Hi Alp,
> >
> > Thanks for helping !
> >
> > 1] Is there a way I could tell libclang which target to initialize
> without
> > modifying it ?
> > 2] How does it work for gcc style assembly, is there a similar error
> > message or does it work without the need of any targets ?
> > 3] Since you decided to diagnose this, you might also want to check the
> > case were the target have been initialized, but not the used function
> > pointers of this target
> >
> > William.
> >
> >
> > On Wed, Oct 30, 2013 at 3:53 PM, Alp Toker <alp at nuanti.com> wrote:
> >
> >>  Hello William,
> >>
> >> I've landed a fix in r193685 to diagnose this instead of crashing:
> >>
> >> clang/test/Index/ms-asm-no-target.cpp:8:3: error: MS-style inline
> >> assembly
> >> is not available: Unable to find target for this triple (no targets are
> >> registered)
> >>
> >> It's up to the embedder to decide what targets are linked in, so how the
> >> API exposes that is still an open question.
> >>
> >> Alp.
> >>
> >>
> >>
> >> On 30/10/2013 11:50, William Ledoux wrote:
> >>
> >> Hello,
> >>
> >> The following minimal code that contain MS-style inline assembly will
> >> compile fine with clang, but libclang fails to parse it
> >> (clang_parseTranslationUnit will return NULL).
> >>
> >>    void Break(){ __asm { int 3 } }
> >>
> >> In yesterday's llvm and clang sources, the problem occurs in
> >> ParseMicrosoftAsmStatement.
> >> In the code below, because no target have been registered, the first
> >> line
> >> will set TheTarget to NULL, and the second line will dereference
> >> TheTarget,
> >> thus causing the problem.
> >>
> >>    const llvm::Target *TheTarget =
> >> llvm::TargetRegistry::lookupTarget(TT,
> >> Error);
> >>    OwningPtr<llvm::MCRegisterInfo> MRI(TheTarget->createMCRegInfo(TT));
> >>
> >> For what I understood, clang, in cc1_main, will initialize targets and
> >> targets' functions with the following 4 lines, whereas libclang won't.
> >>
> >>   llvm::InitializeAllTargets();
> >>   llvm::InitializeAllTargetMCs();
> >>   llvm::InitializeAllAsmPrinters();
> >>   llvm::InitializeAllAsmParsers();
> >>
> >> Just for testing purpose, adding those 4 lines somewhere in
> >> clang_createIndex fixes the problem. I know this is probably wrong, but
> >> did
> >> it just to see if more problems were hiding behind.
> >>
> >> So my questions are:
> >>   1] Is it wanted that libclang doesn't initialize any target ?
> >>   2] if yes, how shloud it behave with MS inline assembly ?
> >>   3] if no, what is the proper way to make it initialize targets ?
> >>
> >> Many thanks for you work !
> >> William
> >>
> >>
> >>
> >>
> >> --
> >> View this message in context:
> >>
> http://clang-developers.42468.n3.nabble.com/libclang-crash-when-parsing-MS-style-inline-assembly-tp4035432.html
> >> Sent from the Clang Developers mailing list archive at Nabble.com.
> >> _______________________________________________
> >> cfe-dev mailing
> >> listcfe-dev at cs.uiuc.eduhttp://
> lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> >>
> >>
> >> -- http://www.nuanti.com
> >> the browser experts
> >>
> >>
> > _______________________________________________
> > cfe-dev mailing list
> > cfe-dev at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20131030/9e9eb0be/attachment.html>


More information about the cfe-dev mailing list