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

Richard Barton richard.barton at arm.com
Thu Nov 7 10:10:32 PST 2013


Hi all

[Adding Alp - didn't realise he was missed off my original mail.]

Looking at the code in lib/Parse/ParseStmt.cpp it looks as though this test
can only be expected to pass when targeting x86 or x86_64. Any other
architecture emits the "Unsupported architecture 'aarch64' for MS-style
inline assembly" message.

I'd like to XFAIL the test for all the other backends. I've committed the
patch (r194211) Please holler if you disagree.

Thanks,
Rich


> -----Original Message-----
> From: cfe-dev-bounces at cs.uiuc.edu [mailto:cfe-dev-bounces at cs.uiuc.edu] On
> Behalf Of Richard Barton
> Sent: 04 November 2013 15:25
> To: mcrosier at codeaurora.org; William Ledoux
> Cc: cfe-dev at cs.uiuc.edu
> Subject: Re: [cfe-dev] libclang crash when parsing MS-style inline
assembly
> 
> Hi all
> 
> Apologies in advance that I don't fully understand the technicalities of
this area,
> but could that regression test be made more robust?
> 
> My clang build has LLVM_DEFAULT_TARGET=aarch64-none-eabi (Host is
> x86_64-linux-gnueabi) and the error message that I get is slightly
different
> causing the test to fail:
> 
> .../ms-asm-no-target.cpp:8:3: error: Unsupported architecture 'aarch64'
for MS-
> style inline assembly
> 
> Again, I don't fully understand the area, but the test seems only to
require that
> an x86 backend is available. It doesn't account for cross-compiling or
when the
> default triple is not x86. If the test needs to be run on x86, shouldn't
the
> REQUIRES line be more strict? Alternatively, if my failure mode is equally
> acceptable behaviour, could the two error messages be combined?
> 
> Thanks,
> Rich
> 
> 
> > -----Original Message-----
> > From: cfe-dev-bounces at cs.uiuc.edu [mailto:cfe-dev-bounces at cs.uiuc.edu]
> > On Behalf Of mcrosier at codeaurora.org
> > Sent: 30 October 2013 15:58
> > To: William Ledoux
> > Cc: cfe-dev at cs.uiuc.edu
> > Subject: Re: [cfe-dev] libclang crash when parsing MS-style inline
> assembly
> >
> > > Hi Chad,
> > >
> > > 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.
> >
> > Unfortunately, I don't have an answer here.  Perhaps Alp or another
> > member
> of
> > the list has a solution.
> >
> > >
> > > 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-par
> > >> si ng-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
> > >> >
> > >>
> > >>
> > >>
> > >
> >
> >
> > _______________________________________________
> > cfe-dev mailing list
> > cfe-dev at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> 
> 
> 
> 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev







More information about the cfe-commits mailing list