Is there any way to find out what lines of a project run in all units like a log? For example :

unit1 line 345 unit1 line 346 unit1 line 347 unit1 line 348 unit2 line 123 unit2 line 256 unit3 line 1252 unit3 line 1253

Regards, Ara

As in code coverage?

The best I can think of is valgrind (linux only), with kcachegrind. It doesn't give you a log, but you can view all code, and it tells you which lines were run, which function was called from which others, ...

The cost is, that your app will run much,much slower during the test.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20150810/084e8d02/attachment.html>

So there isnt any option or implement in debugger that it log what lines it go and it compile? I dont know much about compilers but when it know what lines it run and debug so it can write it some where.

Regards, Ara

Aradeonas wrote

I dont know much about compilers but when it know what lines it run and debug so it can write it some where.

You could accomplish what you want (I think) with a minor tweak to fpprofiler [https://github.com/graemeg/fpprofiler].

fpprofiler is a "poor mans profiler" written in Object Pascal. It inserts profiling lines in your source code. You then compiler and run it, which generates profile output which you could process later. It shouldn't be hard to tweak the profile output to instead output the execution order.

Because it inserts profiling lines in your code, it adjusts the line numbers, but for profiling [and I think want you want], that shouldn't matter much.

Regards,
- Graeme -

Thank you.
But its interesting also how we can find out what is debugger doing.

Regards,
Ara

Aradeonas wrote

So there isnt any option or implement in debugger that it log what lines it go and it compile?

You are looking for complied or executed lines?

Compiled lines: just look for the blue dots, while the debugger runs Executed lines: No current plan.

For executed lines this needs a specially optimized debugger. If you do that with gdb in the IDE, your app would run really slow. Even in valgrind, an app can slow down by a factor of 30 to 50. (values estimated from memory).

The IDE+gdb based debugger is not fit for that. If someone wants to do that based on the new fpdebug, that may be possible. But that needs a volunteer.

I dont know much about compilers but when it know what lines it run and debug so it can write it some where.

You can single step the app in the IDE (of course you need to keep pressing F7), the IDE will record the last 20 lines in the Debug-history window. But this kind of single stepping is very very slow.

valgrind also uses single stepping. but because it is not doing all the tasks other debuggers would do, it ends up with a slowdown that makes it still possible (though sometimes painful) to run an app.

Without single stepping, your app would need to log the info from within. But the complier does not do that. There is fpprofiler. It does not do what you want, but it can probably be modified to do it. It takes your source before compilation, and inserts extra statements (preprocessing).
So all you need is to insert (automatically) one log-statement on each line.

Aradeonas wrote

Thank you. But its interesting also how we can find out what is debugger doing.

Depends on what you want to know. You can see the interaction between the IDE and GDB in
Menu: View > Debug Window > Debug output.

I want to know executed lines,I dont care about debugging in the mean time but I want to know what lines will executed,debugger know that so there should be a way to get this from it.

From the time I start programming years ago I like to know the lines

will executed,its sometimes useful and also interesting.

Regards,
Ara

Aradeonas wrote

I want to know executed lines,I dont care about debugging in the mean time but I want to know what lines will executed,debugger know that so there should be a way to get this from it.

Actually the debugger does not always know what lines were executed. (But feel free to read the gdb docs)

It only:
- has a list of *all* liens that are in the exe, and that may or may not be executed.
- it knows when a line with a breakpoint is hit
- it knows when and which lines are single stepped. If you use run (instead of step) between breakpoints, then which of the lines in between were executed is not known.

Now of course you can single step the entire app (or set breakpoints on al lines). Then you will get this list. But as I said, with the current gdb based debugger, that will be incredible slow.
(valgrind does the single stepping, but it does not have the overhead of interprocess communication between IDE and gdb)

Well newer gdb actually have a record mode, but not on all platforms. And I do not know if they allow to query the executed lines. The data is used for reverse execution. Anyway that is not available inside the IDE.

You can probably get a standalone gdb to do the singlestepping. Not sure but I guess it will still be slower than valgrind.

Again it can be added to the new fpdebug. But someone needs to do that. In fact it would be nice. Coverage is an important factor of testcases for example.

>From the time I start programming years ago I like to know the lines will executed,its sometimes useful and also interesting.

Well you can always start the app in the debugger, and single step (set a breakpoint at the start, press F9 to run, then F7 and continue with f7, F7, F7, ....)
It will take forever, but you see every line that is executed .

Just make sure (in the options) that the project, and all packages of interest have debug info enabled.

However single stepping does not create a "logfile" of all lines.

Martin Frb wrote

Again it can be added to the new fpdebug.

Does fpdebug still have a (human) interactive interface, like duby used to have? Or does it only do app-to-app communications now?

Regards,
- Graeme -

The IDE is interactive? Do you men a console style? Not sure. There was a console interface, and it might still work.

Martin Frb wrote

Do you men a console style? Not sure. There was a console interface, and it might still work.

Yes, I meant if you run the fpdebug debugger from the command prompt (not via the IDE). I'll go have a look to see what is there.

Regards,
- Graeme -