Feature #8743
closedETV in Bridge does not replace function call by a provided entry_point comment
0%
Description
It seems that the replacement works only if an enter function with "entry point" tag also has a different thread number, but if the tag is given without thread switch then it is ignored erroneously.
Files
Updated by Ilja Zakharov over 6 years ago
- File error trace(3).json error trace(3).json added
- File etv.png etv.png added
There is an example here.
In the attached error trace instead of "ldv_emg_usb_register_driver" should be text "Register USB callbacks. (Relevant to 'ldv_driver')" with an "eye". In the corresponding json there is also required tag:
{
"enter": 5,
"entry_point": "Register USB callbacks. (Relevant to 'ldv_driver')",
"file": 1,
"source": "ldv_emg_usb_register_driver(&ldv_driver, &__this_module, \"usb_invoke\");",
"source node": 15,
"start line": 43,
"target node": 16,
"thread": 1
}
But on the screenshot the comment is omitted completely.
Updated by Evgeny Novikov over 6 years ago
- Status changed from New to Feedback
- Target version changed from 2.0 to 1.1
Ilja, please, check whether the issue still exists. As far as I understand recently you fixed some related issues in Core.
Updated by Ilja Zakharov over 6 years ago
- File error trace(14).json error trace(14).json added
- Status changed from Feedback to Open
Yes, it is still relevant. There is no comment in visualization but it is given in the json:
"entry_point": "Register 'usb' callbacks. (Relevant to 'ldv_driver')"
Updated by Evgeny Novikov over 6 years ago
- Target version changed from 1.1 to 2.0
Let's Vladimir will fix it after his vacation.
Updated by Vladimir Gratinskiy over 6 years ago
Ilja Zakharov wrote:
There is an example here.
In the attached error trace instead of "ldv_emg_usb_register_driver" should be text "Register USB callbacks. (Relevant to 'ldv_driver')" with an "eye". In the corresponding json there is also required tag:
{
"enter": 5,
"entry_point": "Register USB callbacks. (Relevant to 'ldv_driver')",
"file": 1,
"source": "ldv_emg_usb_register_driver(&ldv_driver, &__this_module, \"usb_invoke\");",
"source node": 15,
"start line": 43,
"target node": 16,
"thread": 1
}But on the screenshot the comment is omitted completely.
There is no tag "code" in this json, but it is required.
Updated by Vladimir Gratinskiy over 6 years ago
Vladimir Gratinskiy wrote:
There is no tag "code" in this json, but it is required.
Sorry, "code" is internal tag only.
Updated by Evgeny Novikov over 6 years ago
- Status changed from Feedback to Open
Vladimir Gratinskiy wrote:
Vladimir Gratinskiy wrote:
There is no tag "code" in this json, but it is required.
Sorry, "code" is internal tag only.
Then the ball is in your court.
Updated by Vladimir Gratinskiy over 6 years ago
Comments (function names and after it entry_point with similar behavior) are supposed to be shown only if they are not hidden under the "eye" (like in your case). The "eye" opens hidden content and shows real code in the line.
Updated by Evgeny Novikov over 6 years ago
- Tracker changed from Bug to Feature
- Detected in build deleted (
svn)
Vladimir Gratinskiy wrote:
Comments (function names and after it entry_point with similar behavior) are supposed to be shown only if they are not hidden under the "eye" (like in your case). The "eye" opens hidden content and shows real code in the line.
So, let's consider this as a feature request, i.e. opening an eye shouldn't open all nested eyes replacing comments with actual source code.
Updated by Vladimir Gratinskiy over 6 years ago
Evgeny Novikov wrote:
Vladimir Gratinskiy wrote:
Comments (function names and after it entry_point with similar behavior) are supposed to be shown only if they are not hidden under the "eye" (like in your case). The "eye" opens hidden content and shows real code in the line.
So, let's consider this as a feature request, i.e. opening an eye shouldn't open all nested eyes replacing comments with actual source code.
You can always put comment to "source".
Updated by Evgeny Novikov over 6 years ago
Vladimir Gratinskiy wrote:
Evgeny Novikov wrote:
Vladimir Gratinskiy wrote:
Comments (function names and after it entry_point with similar behavior) are supposed to be shown only if they are not hidden under the "eye" (like in your case). The "eye" opens hidden content and shows real code in the line.
So, let's consider this as a feature request, i.e. opening an eye shouldn't open all nested eyes replacing comments with actual source code.
You can always put comment to "source".
But how will be I able to see source without comment and comment without source like for, say, ldv_init()?
Updated by Vladimir Gratinskiy over 6 years ago
Evgeny Novikov wrote:
Vladimir Gratinskiy wrote:
Evgeny Novikov wrote:
Vladimir Gratinskiy wrote:
Comments (function names and after it entry_point with similar behavior) are supposed to be shown only if they are not hidden under the "eye" (like in your case). The "eye" opens hidden content and shows real code in the line.
So, let's consider this as a feature request, i.e. opening an eye shouldn't open all nested eyes replacing comments with actual source code.
You can always put comment to "source".
But how will be I able to see source without comment and comment without source like for, say, ldv_init()?
You don't need source if it will be included into the comment.
Updated by Evgeny Novikov over 6 years ago
Vladimir Gratinskiy wrote:
Evgeny Novikov wrote:
Vladimir Gratinskiy wrote:
Evgeny Novikov wrote:
Vladimir Gratinskiy wrote:
Comments (function names and after it entry_point with similar behavior) are supposed to be shown only if they are not hidden under the "eye" (like in your case). The "eye" opens hidden content and shows real code in the line.
So, let's consider this as a feature request, i.e. opening an eye shouldn't open all nested eyes replacing comments with actual source code.
You can always put comment to "source".
But how will be I able to see source without comment and comment without source like for, say, ldv_init()?
You don't need source if it will be included into the comment.
Can you, please, clarify your suggestion in terms of JSON and subsequent visualization? Perhaps, I don't understand your point.
Updated by Vladimir Gratinskiy over 6 years ago
For the example in the 1st comment:
"source": "ldv_emg_usb_register_driver(&ldv_driver, &__this_module, \"usb_invoke\"); // Register USB callbacks. (Relevant to 'ldv_driver')"
Updated by Evgeny Novikov over 6 years ago
Vladimir Gratinskiy wrote:
For the example in the 1st comment:
"source": "ldv_emg_usb_register_driver(&ldv_driver, &__this_module, \"usb_invoke\"); // Register USB callbacks. (Relevant to 'ldv_driver')"
This isn't great, as all these comments are dedicated to hide corresponding artificial pieces of code (or corresponding sequences of witness edges) but have an ability to see them in a raw way (primarily for "debugging" purposes, e.g. when users want to know that a generated environment model isn't valid).
Updated by Vladimir Gratinskiy about 6 years ago
- Status changed from Open to Resolved
Implemented in "bridge-2.0" branch. The rule is "Eye can't hide eye", so call stack to node with entry_point will be always shown like for nodes with "warn" label.
Updated by Evgeny Novikov about 6 years ago
- Status changed from Resolved to Closed
Tests passed, so, I merged the branch to master in b8bda00ac.