Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

@gerion0
Copy link
Contributor

@gerion0 gerion0 commented Jul 28, 2021

See #485.

I have tested the code with https://gitlab.com/geri0n/svf-test/-/tree/llvmtovfg.

The back map seems not to work with these nodes (since the PAGNodes are not linked to llvm::Values):

  • ActualParmSVFGNode
  • FormalRetVFGNode
  • IntraPHIVFGNode

Moreover an assert in the map filling code does not work: pag->getPAGEdgeNum() give me way more edges, than I can find in the graph.

Function equivalent but gives better error detection of the compiler.
@gerion0
Copy link
Contributor Author

gerion0 commented Jul 28, 2021

How can I reproduce the tests locally? I have tried:

$ cd Test-Suite; ./generate_bc.sh
$ cd build; ctest -VV

This results in:

100% tests passed, 0 tests failed out of 114

However, Github reports 405 tests.

@yuleisui
Copy link
Collaborator

Unfortunately, the test suite failed. It seems to me that it was because wpa was not generated sucessfully.

Could you break down this patch into two?
(1) minor changes for code cleaning/formating or some helpful data structures will be used later (in order to pass the CI)
(2) code only related to SVFG.h/.cpp for your mapping

@gerion0
Copy link
Contributor Author

gerion0 commented Jul 29, 2021

I will do a binary search via forced push. Please do not merge.

Howe can I reproduce the tests locally?

@yuleisui
Copy link
Collaborator

I will do a binary search via forced push. Please do not merge.

Howe can I reproduce the tests locally?

You can take a look at this github workflow file. It basically tells the configuration for testing locally.
https://github.com/SVF-tools/SVF/blob/master/.github/workflows/github-action.yml

if(hasDef(pagNode)) {
ret.emplace(getDefSVFGNode(pagNode));
}
return ret;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We do not return the local set. Pass a reference set as a parameter?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The set is moved in these cases, so there shouldn't be a problem.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you make this function public, it may be accidentally used by other users. I would suggest making the function like:
void SVFG::fromLLVMValue(const llvm::Value* value, std::set<const SVFGNode*>& nodeset) const;' where nodeset` is a reference referring to set in the caller, so that we will not return a local set.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here applies what I said in the other comment. Returning a set or specifying a reference parameter leads to the same code.

Theoretical, the local set is returned by a copy. However, in practice it is moved, see https://isocpp.org/blog/2013/02/no-really-moving-a-return-value-is-easy-stackoverflow

edge_count++;
}
}
errs() << "NodeCount" << node_count << " NodeNum: " << pag->getTotalNodeNum() << " " << pag->getPAGNodeNum() << "\n";
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

delete these output messages.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have inserted these messages only because the assertion a few lines later does not work. Can you elaborate on that?
Why is getTotalEdgeNum() different to edge_count?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is strange. Could you have a look at where these two counters getTotalEdgeNum() and edge_count are increamented?

gerion0 added 4 commits July 30, 2021 02:52
A PHIVFGNode links to a PAGNode instead of an edge.
Backmapping does not work with
- ActualParmSVFGNode
- FormalRetVFGNode
- IntraPHIVFGNode

Closes: SVF-tools#485

/// Return the corresponding SVFGNodes to a given llvm::Value.
/// return an empty list, if the no mapping is possible
std::set<const SVFGNode*> fromLLVMValue(const llvm::Value* value) const;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please also remove the namespace here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should I also change the function name to fromValue then?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, please.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you please change this name so that I could merge?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Was on vacation. See #497.

@yuleisui yuleisui merged commit cf3f4bb into SVF-tools:master Aug 8, 2021
gerion0 added a commit to luhsra/SVF that referenced this pull request Aug 16, 2021
@gerion0
Copy link
Contributor Author

gerion0 commented Nov 3, 2022

Appearantly, the newly added function fromValue was removed again in cfb6657. Why was it removed?

Edit: I have replaced it now with

SVF::SVFG vfg;
llvm::Value* value;
vfg.getSVFGNode(vfg.getPAG()->getValueNode(value));

Is this more less equivalent?

@yuleisui
Copy link
Collaborator

yuleisui commented Nov 3, 2022

Yes, please add it back. The reason was that we may have SVFValue to replace llvm::Value later.

@gerion0
Copy link
Contributor Author

gerion0 commented Nov 4, 2022

I have edited my post previously. Is the proposed solution more less equivalent?

Especially, the old solution relies on the PAGEdgeToStmtVFGNodeMap which seems to be removed in the meantime.

@yuleisui
Copy link
Collaborator

yuleisui commented Nov 4, 2022

I have edited my post previously. Is the proposed solution more less equivalent?

Yes.

Especially, the old solution relies on the PAGEdgeToStmtVFGNodeMap which seems to be removed in the meantime.

@gerion0 gerion0 mentioned this pull request Nov 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants