-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve handling of java/lang/System
entry points in CG generation
#241
base: develop
Are you sure you want to change the base?
Improve handling of java/lang/System
entry points in CG generation
#241
Conversation
…treams as instantiated by default
Thank you for the extensive investigation and the PR. I fully agree with the additions to the config and with adding instantiated types to I'm a little wary however with For the last future work item: That is a fair point. I think we could deal with it like you suggested, though maybe rather than setting them to the field type, they could access the |
…actor config so that instantiated fields can be user supplied
I think you make a good point. I restructured parts of this PR so that now:
I think this might be a good solution to the problem - analyses for android can just remove the three lines from the configuration, and they also don't introduce any overhead of libraries are not loaded at all. Regarding your suggestion for associating library fields with What do you think of this idea, does that work for you? |
Oh i forgot to mention: The |
This solution sounds reasonable. Thank you for your work! About the |
My latest commit adds support for the initial intantiated fields to CFA-1-0 and CFA-1-1. For the latter i had to create dummy allocation sites as the fields are defined in native code - i don't know if that is the way to go, but it seems to work as expected. So regarding the library fields and the
Is there any specific reason you think we should use the second option? I'm currently thinking the first one should be less overhead, but maybe i'm missing something .. 🤓 |
You can have a look at The main reason for choosing the second option would be to have fewer necessary modifications. For RTA, it would work immediately, as RTA just uses instantiated types and thus the proper InitialInstantiatedTypesFinder will automatically make it work. For the propagation-based ones it would be just the single line that adds the InitialInstantiatedTypes to the ExternalWorld that we probably want to have anyway. The InstantiatedFieldsFinders would not be necessary. For the points-to-based algorithms, it should be similar: one handling for instantiated types (that we probably need anyway if we don't yet have it) instead of that and the additional one for the fields. |
OPAL/br/src/main/scala/org/opalj/br/analyses/cg/InitialInstantiatedFieldsKey.scala
Outdated
Show resolved
Hide resolved
There are two points why i think the first option may be the better one:
So in my mind, if we want to capture fields being set in native code - and i'm open to discussing whether or not we want that - then we need an That being said, if you want me to implement the second option i'll do that - justed wanted to point that out 😄 |
Shouldn't the second point already be addressed by the configured native methods analyses? I thought it was. |
After discussion, we will proceed as follows:
|
After some further inspection i think this is not going to be as easy as we thought it would. I found that:
If my assessment is correct, i think the following steps would be sensible to take next:
What do you think of this? Is this the right way to go? |
You are right, they are configured to use the RTA class there, which doesn't seem to make much sense. Not sure why that is, I thought there already was a variant for XTA, but apparently, there isn't. So yes, it looks like we need to add that. For the other issue, it looks like entry points should always be considered, even without a body. I don't think it is necessary that they have configuration attached, they could still just exist without any callees. They should probably exist (so you don't get spurious methods in the CG that are configured as entry point for a different setup than you analyze), but bodies should not be necessary. I wonder why removing the emptiness check didn't just work, so yes, that should be looked into. Thank you for your investigation! |
…d types analysis for XTA family
…nalysis to work for empty methods as well - same for configured call graph analysis. Currently this breaks CFA, needs to be adapted next
This PR resulted from issues discussed in #230, in particular the fact that calls to
System.out.println
are not found by OPAL with multiple CG algorithms when theRTJar
is loaded (either interfaces-only or fully). The reasons for this are depending on the CG algorithm and configuration, but boil down to:PrintWriter
(the type ofSystem.out
) whenRTJar
is loaded as interfaces only - it is simple never instantiatedSystem.initializeSystemClass
(which we model as an initial entrypoint in the config) to usingSystem.initPhase1
,System.initPhase2
andSystem.initPhase3
- all of which are called from native code and currently not configered to be initial entry points. This is another reason why RTA - even when the RTJar is loaded fully - does not find calls toprintln
.System.out
that initializes the field (even whenRTJar
is loaded fully) - the reason for this is that the fields are set in native codeSide-Note: This was never a problem when the
RTJar
was not loaded, becauseCallGraphAnalysis.unknownLibraryCall
caught any calls to virtual methods (likeprintln
in this scenario).Changes in this PR
This PR introduces some changes to tackle the problems mentioned above. This includes:
initPhase1
,initPhase2
andinitPhase3
of typejava/lang/System
to be initial entry points in the config - see the OpenJDK implementation for details on this.java/lang/Thread
,java/lang/ClassLoader
,java/io/PrintStream
andjava/io/InputStream
to be instantiated via configSystem.out
,System.in
andSystem.err
are instantiated with their declared types by adding them to the respectivetypeSetEntity
- furthermore, we now always assume that the configured instantiated types are available for theExternalWorld
type set entity.With these changes CHA, RTA and all Propagation-Based CG algorithms will now find calls to
System.out.println
, regardless of whether theRTJar
is loaded at all, as interfaces only, or fully.What's still to do
println
and fix the issueExternalWorld
because their definition is available, therefore they cannot be treated differently compared to "normal" project fields. Decide on whether those cases deserve special handling or not - we might just have to live with that fact. The only way of dealing with the would be something likeif(isLibraryField(field) && librariesAreInterfacesOnly) considerInstatiated(typeSetEntity(field), field.fieldType)