On 19.02.2018 12:17, Ondrej Pokorny wrote: > On 19.02.2018 11:14, Sven Barth via fpc-devel wrote: >> Am 19.02.2018 11:01 schrieb "Ondrej Pokorny" <laza...@kluug.net >> <mailto:laza...@kluug.net>>: >> >> I agree with Simon here. It's a similar scenario like heaptrc. Why >> not to add a compiler parameter to include profiling info? That >> would be just great. >> >> >> It's not the same scenario as heaptrc is entirely working in the RTL >> without any compiler extension (aside from the -gh parameter). > > First of all - if you read my sentence again I said it is a */similar/* > scenario and not the */same/* scenario. > > BUT: to be completely exact a small compiler extension comes with -gh as > well and that you cannot achieve with the RTL - if > http://wiki.freepascal.org/heaptrc is not wrong: /Note: Do not add the > heaptrc unit manually. The heaptrc unit needs to be loaded before > lineinfo and only the compiler can do that./
This is only true if you rely on "-gl". Nothing stops you from manually adding the "lineinfo" or "lnfodwrf" unit while using e.g. "-gw2" (in this case "lnfodwrf" needs to be used of course). Then you simply add "heaptrc" before the line information unit and you're set... The only difference will be that the compiler is also able to load those two units before the "objpas" unit is loaded which you can't do manually, but that doesn't change much regarding the capability of heaptrc to detect memory leaks. > > So yes, -gh injects the heaptrc unit in front of lineinfo and the > profiling compiler parameter injects profiling code into every compiled > procedure/method. Don't tell me you don't see any similarities here :) > And yes, even the word "same" can be seen as valid here, if you like > word games :) > > Second: FPProfiler works already now entirely in the RTL without any > compiler extension. Your above statement just doesn't make sense. FPProfiler works *with* the RTL (and packages) to *modify* the source and then calls the compiler. However from within the program itself you can't modify your own source code and instead need to rely on the compiler to insert suitable calls for you (like you showed below). This nevertheless requires more changes to the compiler than adding a switch that allows loading a specific unit before another specific one. >> Profiling code however would require extensions to the compiler >> whereby it would also need to handle exceptions correctly and such things. > > Yes, I am again absolutely aware of this and I still believe it's > possible and probably even not that hard to achieve. You just need to > inject a try-finally block (= "handles exceptions correctly") around > every procedure/function block: > > procedure Test; > begin > EnterProfiling('MyUnit.Test'); > try > // <<< real code here > finally > LeaveProfiling('MyUnit.Test'); > end; > end; > > Of course EnterProfiling and LeaveProfiling must be thread safe (every > thread to be profiled separately) - and they even can be a part of the > RTL, the same as heaptrc code is. EnterProfiling and LeaveProfiling must > eat all intern exceptions - this is perfectly doable in the RTL. Yes, the bulk of the code that does keeps track of the profiling can and should be done in the RTL (or with a hookable approach so that 3rdparty code can extend it), but without the compiler inserting the calls to those functions you have nothing. The heaptrc and line information can still be used without such compiler support, even if the compiler should not generate debug information. > All in all, in my eyes absolutely doable and a great and valid compiler > extension. And again - very very similar scenario to heaptrc, if you > don't like the word "same". I didn't say anything *against* adding this to the compiler, I had the idea myself some time ago to implement this, but what I'm sensitive about is you comparing one feature with another and saying they are similar when they are not. Regards, Sven _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel