Project

General

Profile

Actions

Feature #8743

closed

ETV in Bridge does not replace function call by a provided entry_point comment

Added by Ilja Zakharov about 6 years ago. Updated over 5 years ago.

Status:
Closed
Priority:
Urgent
Category:
Bridge
Target version:
Start date:
02/27/2018
Due date:
% Done:

0%

Estimated time:
Published in build:

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

error trace(3).json (30.2 KB) error trace(3).json Ilja Zakharov, 02/27/2018 02:24 PM
etv.png (36.8 KB) etv.png Ilja Zakharov, 02/27/2018 02:25 PM
error trace(14).json (31.7 KB) error trace(14).json Ilja Zakharov, 07/18/2018 01:53 PM

Updated by Ilja Zakharov about 6 years ago

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.

Actions #2

Updated by Evgeny Novikov almost 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.

Actions #3

Updated by Ilja Zakharov almost 6 years ago

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')" 

Actions #4

Updated by Evgeny Novikov almost 6 years ago

  • Target version changed from 1.1 to 2.0

Let's Vladimir will fix it after his vacation.

Actions #5

Updated by Vladimir Gratinskiy almost 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.

Actions #6

Updated by Evgeny Novikov almost 6 years ago

  • Status changed from Open to Feedback

What's next?

Actions #7

Updated by Vladimir Gratinskiy almost 6 years ago

Vladimir Gratinskiy wrote:

There is no tag "code" in this json, but it is required.

Sorry, "code" is internal tag only.

Actions #8

Updated by Evgeny Novikov almost 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.

Actions #9

Updated by Vladimir Gratinskiy almost 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.

Actions #10

Updated by Evgeny Novikov almost 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.

Actions #11

Updated by Vladimir Gratinskiy almost 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".

Actions #12

Updated by Evgeny Novikov almost 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()?

Actions #13

Updated by Vladimir Gratinskiy almost 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.

Actions #14

Updated by Evgeny Novikov almost 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.

Actions #15

Updated by Vladimir Gratinskiy almost 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')"

Actions #16

Updated by Evgeny Novikov almost 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).

Actions #17

Updated by Vladimir Gratinskiy over 5 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.

Actions #18

Updated by Evgeny Novikov over 5 years ago

  • Status changed from Resolved to Closed

Tests passed, so, I merged the branch to master in b8bda00ac.

Actions

Also available in: Atom PDF