This is an archive of the discontinued LLVM Phabricator instance.

Provide the name for labels inside MS asm blocks to clang as the branch targets for each asm block
AbandonedPublic

Authored by ehsan on Sep 28 2014, 6:52 PM.

Details

Reviewers
rnk
Summary

These branch targets will help clang diagnose jumps across inline MS asm blocks.

Diff Detail

Event Timeline

ehsan updated this revision to Diff 14151.Sep 28 2014, 6:52 PM
ehsan retitled this revision from to Provide the name for labels inside MS asm blocks to clang as the branch targets for each asm block.
ehsan updated this object.
ehsan edited the test plan for this revision. (Show Details)
ehsan added a reviewer: rnk.
ehsan added a subscriber: Unknown Object (MLST).
rnk edited edge metadata.Sep 29 2014, 10:50 AM

I don't think we need this, LookupInlineAsmLabel should be able to track all the LabelDecl's that got created during inline asm parsing.

In D5515#4, @rnk wrote:

I don't think we need this, LookupInlineAsmLabel should be able to track all the LabelDecl's that got created during inline asm parsing.

Well, LookupInlineAsmLabel would not be able to associate a label name with an MSAsmStmt, which we later on need to use in order to check whether the branch target is defined inside another MSAsmStmt on the clang side. Also, note that this patch provides two bits of information, the "labels defined" and the "branch targets". The branch targets cannot be deciphered from LookupInlineAsmLabel, given the fact that you can do things such as mov eax, LabelName that are not branches.

rnk added a comment.Sep 29 2014, 1:35 PM
In D5515#5, @ehsan wrote:

Well, LookupInlineAsmLabel would not be able to associate a label name with an MSAsmStmt, which we later on need to use in order to check whether the branch target is defined inside another MSAsmStmt on the clang side. Also, note that this patch provides two bits of information, the "labels defined" and the "branch targets". The branch targets cannot be deciphered from LookupInlineAsmLabel, given the fact that you can do things such as mov eax, LabelName that are not branches.

I was imagining having ClangAsmParserCallback track a list of defined and used LabelDecls. The 'Create' parameter basically means "this label was defined" and could be renamed to reflect that.

I guess the one thing that is completely lost is the branch information. You only know what uses there are, not if the use is a branch. Is that OK? It means we need to reject this code:

void g();
void *f() {
  __asm foo: nop
  g();
  __asm mov eax, foo
}

I guess I'm OK with that. :)

In D5515#6, @rnk wrote:
In D5515#5, @ehsan wrote:

Well, LookupInlineAsmLabel would not be able to associate a label name with an MSAsmStmt, which we later on need to use in order to check whether the branch target is defined inside another MSAsmStmt on the clang side. Also, note that this patch provides two bits of information, the "labels defined" and the "branch targets". The branch targets cannot be deciphered from LookupInlineAsmLabel, given the fact that you can do things such as mov eax, LabelName that are not branches.

I was imagining having ClangAsmParserCallback track a list of defined and used LabelDecls. The 'Create' parameter basically means "this label was defined" and could be renamed to reflect that.

But ClangAsmParserCallback right now doesn't know whether the create vs use happens within the same asm block... And it is invoked before we even create the corresponding MSAsmStmt, so I'm not sure where it would record this information. Any pointers?

I guess the one thing that is completely lost is the branch information. You only know what uses there are, not if the use is a branch. Is that OK? It means we need to reject this code:

void g();
void *f() {
  __asm foo: nop
  g();
  __asm mov eax, foo
}

I guess I'm OK with that. :)

That would be a bit unfortunate, since my current patch properly accepts that code. But I guess I don't feel very strongly.

ehsan abandoned this revision.Oct 8 2014, 8:21 PM

Abandoned in favor of http://reviews.llvm.org/D5694.