I'm on Ubuntu 18.04, using codeclap 0.9.1 and have compiled with clang 9.0.0
Here is an image to help describe my points:
When I run my program under codeclap, i.e. 'continue' button:
Thanks
Here is an image to help describe my points:
When I run my program under codeclap, i.e. 'continue' button:
- The value of the variables displayed in the source window don't get updated from the garbage uninitialized values (see 'starting_window_width_in_pixels')
- Entering a variable name into the expression window does not give the correct value (see 'player_bc_x')
- Does the expression window update values dynamically? My understanding is that is what a 'watch' window is for, however I cannot find this in codeclap
Thanks
Edited by Ryan
on
Reason: Initial post
Hi Ryan,
the expressions panel updates dynamically and for this situation can be assumed to be the same as the watch panel.
I can't say for certain because the window is blocking the threads panel but it looks like the thread is not in a stopped state (last known stacktrace location is game.c:114).
At least at the moment it is best to inspect variables when the thread is in a stopped state (after/between steps, when hitting a breakpoint), otherwise variable addresses may be wrong when calculated based on the last available thread state (rsp, rbp).
"Realtime debugging" is planned to work better in the future but at the moment is rather unreliable, among other things because there is no controlled window refresh on its own when there is no interaction happening.
There is an edge case where variables would be seen as valid directly starting at the entry point of a function however the address calculation would only be correct after passing the function prologue. This may be part of the explanation of what has happened here.
Can you try stopping the thread at some location where player_bc_x should be available to see if the value is shown correctly in this case?
Hope this helps.
the expressions panel updates dynamically and for this situation can be assumed to be the same as the watch panel.
I can't say for certain because the window is blocking the threads panel but it looks like the thread is not in a stopped state (last known stacktrace location is game.c:114).
At least at the moment it is best to inspect variables when the thread is in a stopped state (after/between steps, when hitting a breakpoint), otherwise variable addresses may be wrong when calculated based on the last available thread state (rsp, rbp).
"Realtime debugging" is planned to work better in the future but at the moment is rather unreliable, among other things because there is no controlled window refresh on its own when there is no interaction happening.
There is an edge case where variables would be seen as valid directly starting at the entry point of a function however the address calculation would only be correct after passing the function prologue. This may be part of the explanation of what has happened here.
Can you try stopping the thread at some location where player_bc_x should be available to see if the value is shown correctly in this case?
Hope this helps.