|
|
Post by bitvast on Nov 25, 2014 13:56:42 GMT 1
Hi Peter,
I was thinking about how the debugging process could be improved in BaCon; the TRACE command would be more useful if you could see the variables change, which currently can only be done by adding PRINT statements at appropriate places in the code. Would it be possible to add a window or area which shows a table of variables? Not sure how this would work with large arrays though.
Maybe there's a way of interfacing BaCon with GDB? but I guess that would only show the translated C program variables.
|
|
|
|
Post by Pjot on Nov 25, 2014 15:57:56 GMT 1
Hi bitvast, Your request is somewhat complicated, as BaCon simply translates code to C. Contrary to an interpreter, which can keep track of each variable name and value, BaCon lazily passes variables as-they-are to the C compiler, which creates a binary. So indeed, somebody trying to trace down a problem in a binary program is stuck with Valgrind or GDB. In GDB for example, it is possible to find out te value of a variable during runtime (see sample session below to get the idea). Note that in all cases you must compile your program using the '-g' flag to preserve symbols and debug information. HTH Peter a = 1
STOP
PRINT a
|
|
|
|
Post by bitvast on Nov 25, 2014 17:29:48 GMT 1
Hi Peter, I see your point, so does the TRACE command just step through each line of the binary and output the corresponding BaCon line? I guess the solution is to take more care over the design of programs and not introduce bugs in the first place.  |
|
|
|
Post by Pjot on Nov 26, 2014 9:35:33 GMT 1
Hi bivast, Well, the TRACE statement adds code to the original program, and this additional code is compiled together with the original code. BaCon does keep track of the types of variables, but does not see what is changed where. It just passes expressions to the C compiler. In Shell script for example, there is the '-x' option, which perfectly shows changes in values and variables at each step. But in BaCon there is no parsing of expressions. to determine which variables are used and changed. Therefore it is somewhat complicated to narrow down the relevance for variables at each step, and print them. So for BaCon, the only way then would be to walk through the list of all used variables and print them all, their type and value, even if this is not valid for the current step. Then, if there is an array of 1000 elements, how would that work? In GDB, it is possible to query each individual element, but BaCon bluntly would just print all of them. Note that there already is a secret '-@' option to BaCon, which will show all variables and their types when conversion is ready (but not their values). If you have a suggestion I'll be happy to look at it... BR Peter EDIT: it maybe could be done interactively, at each step either press <space>, or allow entering a variable name, and then print its value? |
|
|
|
Post by Pjot on Nov 26, 2014 15:04:55 GMT 1
Hi bitvast,
Unfortunately it's not going to work, as BaCon only keeps track of variables during conversion time and not during runtime.
So during conversion time, code is added to go through the program step-by-step. Generally, BaCon only can keep track of things while it is converting, and as it does not actually parses expressions (lazy conversion), no meta information is kept for variables.
In any case, an interactive way of querying variables during runtime also needs a complete housekeeping of all values of variables while converting code. Only then, BaCon can add code (during conversion time) to query a variable during runtime.
So, a compiled program simply can not evaluate a variable during runtime. This can only be done in the world of interpreters.
BR
Peter
|
|
|
|
Post by bitvast on Nov 26, 2014 17:23:53 GMT 1
Hi Peter,
I liked your suggestion of interactively entering variable names, but never mind. Back to the good old PRINT statements. Thanks for looking into it anyway.
|
|
|
|
Post by Pjot on Nov 27, 2014 17:58:11 GMT 1
Hi bitvast, Further hacking, I found some workaround where the user before conversion time has to indicate which variables he/she is interested in. An additional line of code is then needed, like this: This would instruct BaCon that at each TRACE step the variables x, y and z$ need to be printed on the screen. It is a requirement that the variables are used or declared earlier in the program. So the following program would is possible: LOCAL x%
y$ = "12"
TRACE MONITOR x%, y$
FOR x% = 1 TO 10
PRINT x%
y$ = y$ & "3"
NEXT
In this program the variable 'x%' is declared and the variable 'y$' is already assigned. The output would be: Hope this comes close enough to what you are looking for? See also the latest beta. BR Peter |
|
|
|
Post by bitvast on Nov 27, 2014 22:52:43 GMT 1
Peter, This is great, thanks very much! I haven't actually tested it yet, I found a bug which I think relates to the new lowercase keywords/functions option. I'll post details in the bug report section. |
|
|
|
Post by Pjot on Nov 28, 2014 9:55:47 GMT 1
Hi bitvast, Just found a small bug in TRACE MONITOR, please use the latest from this morning. BR Peter |
|
