Re: [SPAM] Re: [Harbour] What is Valtype = S ?
Hi, Viktor Szakáts wrote: The only thing I wonder is why all this is important for a normal user application...? Perhaps because I never needed such thing, but if the goal is to check the arguments involved in an RTE, we have oError:args (just like Clipper). I find it also very useful. I dump function parameters and locals for a the whole HVM stack in case of RTE. If bug is not in the caller function, but a few functions up, oError:args is not enough to find a bug. Regards, Mindaugas ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [SPAM] Re: [Harbour] What is Valtype = S ?
I have not read Przem message yet, > The only thing I wonder is why all this is important > for a normal user application...? I'd like to print ALL the variables (private, public, local) in all stack states, in order to have a complete HVM snapshot, while with oError:args you have only the parameters... It's a "plus" in debugging production codenot strictly necessary, but a plus... Francesco ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [SPAM] Re: [Harbour] What is Valtype = S ?
The only thing I wonder is why all this is important for a normal user application...? Perhaps because I never needed such thing, but if the goal is to check the arguments involved in an RTE, we have oError:args (just like Clipper). Brgds, Viktor On 2010 Mar 3, at 02:40, Przemysław Czerpak wrote: > On Wed, 03 Mar 2010, francesco perillo wrote: > > Hi, > >> I'm writing a personal message so that info won't get public :-) > > OK, but I'm setting CC to harbour-devel list in answer because > it may help other users and I hope future HVM developers :-) to > understand how HVM works. > >> but I must say that at least one function is documented in >> doc/en/hvm.txt: * __DBGVMVARLGET( , ) --> > > Serious mistake. I'll remove it ASAP. > BTW this description is wrong. is not an index to local variable. > >> I now "think to know" what valtype S is in the stack... it IS the >> first item pushed in the stack and is the pointer to the function that >> is going to be executed... >> Let's see in a real life example, where the code from .ppo is DevOut( >> aPrinter[ s_ptr_selec ] ): >> >> Local 13:SSymbol: DEVOUT >> Local 14:U > > "U" is NIL, Try > ? valtype( "NIL" ) > > It's QSELF() value. Inside method it's an object. > >> Local 15:ALen:4 >> Local 16:N13.00 >> Local 17:C"W/B,GR+/W,N/N,B/N,W+/BG,B/N" >> Local 18:N0.00 >> >> aPrinter (local15) has len 4, s_ptr_selec (local16) is 17 so out of >> bound error is generated... > > There are no local variables. There are only items on HVM stack. > Some of them belongs to declared function parameters, some of them > contains additional parameters when user passed more parameters then > was declared by function, some others belongs to local variables and > rest is used by currently executed code, i.e. partially calculated > expressions, WITH OBJECT values, FOR EACH iterators, BEGIN SEQUENCE > envelopes, called function parameters, etc. > The function stack frame contains: > > 1 FUNCTION SYMBOL OR METHOD SYMBOL > 2 QSELF() VALUE (NIL FOR FUNC/PROC, OBJ FOR METHODS) > 3 DECLARED PARAMETERS > ... > 3 + ADDITIONAL PARAMETERS IF PASSED MORE THEN PARAMS > ... > 3 + + LOCAL VARIABLE > ... > 3 + + + ITEMS ALLOCATED BY EXECUTED CODE > ... > 3 + + + + NEXT FUNCTION FRAME SYMBOL > >> I could not explain what Local17 and 18 were for... but then realized >> the following: >> the function has 5 parameters but in this specific case there are only >> 3 of them specified in the function call... >> Since LocalCount = number_of_locals - number_of_params >> and since number_of_params is 2 less than what should be, LocalCount >> is 2 bigger than necessary... and so 2 spurious stack elements are >> printed... >> So, question 1: is it possible to retrieve the number of parameters >> declared in a function ? > > Yes. It's possible to retrieve number of declared parameters (+ in > above scheme). > It's also possible to retrieve number of passed parameters ( in above > scheme) > > It's not possible to detect number of local variables ( in above > scheme) so it's not possible to guess when local variables stops > and begins execution context items. > > It's possible to detect the whole frame size so is also known. > >> Question 2: for object method I get valtype S... but for function >> invocation not always... is there a rule ? > > In all cases you have function or method symbol as 1-st item in > function method frame. > >>> __DBGVMVARL[GS]ET() is internal debug function function and >>> it cannot be used without additional information which is available >>> only for debugger. >> but it works at the moment, in harbour 2.0.0, the one I will use for >> at least one year... > > And after a year you decided to check what it exactly does and you are > asking why your code does not work as you want ;-) > > You can always use any internal HVM functions for your own risk. > It's your choice. I only hope that I do not see any message from > you when we remove above functions i.e. making some modifications > in HVM stack or debugger code. > Is it also possible that the compiler removes local variables (both LOCAL or parameters) present in function definition not used in the function ? or that they are changed position in the LocalX list ? >>> Yes it's possible though in current compiler code it is used only to >>> eliminate unused local variables >> Ok, I had such case... 2 unused locals did shift all the others and >> they didn't match the values. > > No, you do not have such case. > You only wrongly expected that 2-nd parameter of __DBGVMVARL[GS]ET() > function is index to local variables and it isn't. > > In a while I'll add to SVN new function __DBGVMLOCALLIST() which returns > array with and items in the above function frame scheme and > below I'm attaching the code which should help you to understan
Re: [SPAM] Re: [Harbour] What is Valtype = S ?
On Wed, 03 Mar 2010, francesco perillo wrote: Hi, > I'm writing a personal message so that info won't get public :-) OK, but I'm setting CC to harbour-devel list in answer because it may help other users and I hope future HVM developers :-) to understand how HVM works. > but I must say that at least one function is documented in > doc/en/hvm.txt: * __DBGVMVARLGET( , ) --> Serious mistake. I'll remove it ASAP. BTW this description is wrong. is not an index to local variable. > I now "think to know" what valtype S is in the stack... it IS the > first item pushed in the stack and is the pointer to the function that > is going to be executed... > Let's see in a real life example, where the code from .ppo is DevOut( > aPrinter[ s_ptr_selec ] ): > > Local 13:SSymbol: DEVOUT > Local 14:U "U" is NIL, Try ? valtype( "NIL" ) It's QSELF() value. Inside method it's an object. > Local 15:ALen:4 > Local 16:N13.00 > Local 17:C"W/B,GR+/W,N/N,B/N,W+/BG,B/N" > Local 18:N0.00 > > aPrinter (local15) has len 4, s_ptr_selec (local16) is 17 so out of > bound error is generated... There are no local variables. There are only items on HVM stack. Some of them belongs to declared function parameters, some of them contains additional parameters when user passed more parameters then was declared by function, some others belongs to local variables and rest is used by currently executed code, i.e. partially calculated expressions, WITH OBJECT values, FOR EACH iterators, BEGIN SEQUENCE envelopes, called function parameters, etc. The function stack frame contains: 1 FUNCTION SYMBOL OR METHOD SYMBOL 2 QSELF() VALUE (NIL FOR FUNC/PROC, OBJ FOR METHODS) 3 DECLARED PARAMETERS ... 3 + ADDITIONAL PARAMETERS IF PASSED MORE THEN PARAMS ... 3 + + LOCAL VARIABLE ... 3 + + + ITEMS ALLOCATED BY EXECUTED CODE ... 3 + + + + NEXT FUNCTION FRAME SYMBOL > I could not explain what Local17 and 18 were for... but then realized > the following: > the function has 5 parameters but in this specific case there are only > 3 of them specified in the function call... > Since LocalCount = number_of_locals - number_of_params > and since number_of_params is 2 less than what should be, LocalCount > is 2 bigger than necessary... and so 2 spurious stack elements are > printed... > So, question 1: is it possible to retrieve the number of parameters > declared in a function ? Yes. It's possible to retrieve number of declared parameters (+ in above scheme). It's also possible to retrieve number of passed parameters ( in above scheme) It's not possible to detect number of local variables ( in above scheme) so it's not possible to guess when local variables stops and begins execution context items. It's possible to detect the whole frame size so is also known. > Question 2: for object method I get valtype S... but for function > invocation not always... is there a rule ? In all cases you have function or method symbol as 1-st item in function method frame. > > __DBGVMVARL[GS]ET() is internal debug function function and > > it cannot be used without additional information which is available > > only for debugger. > but it works at the moment, in harbour 2.0.0, the one I will use for > at least one year... And after a year you decided to check what it exactly does and you are asking why your code does not work as you want ;-) You can always use any internal HVM functions for your own risk. It's your choice. I only hope that I do not see any message from you when we remove above functions i.e. making some modifications in HVM stack or debugger code. > >> Is it also possible that the compiler removes local variables (both > >> LOCAL or parameters) present in function definition not used in the > >> function ? or that they are changed position in the LocalX list ? > > Yes it's possible though in current compiler code it is used only to > > eliminate unused local variables > Ok, I had such case... 2 unused locals did shift all the others and > they didn't match the values. No, you do not have such case. You only wrongly expected that 2-nd parameter of __DBGVMVARL[GS]ET() function is index to local variables and it isn't. In a while I'll add to SVN new function __DBGVMLOCALLIST() which returns array with and items in the above function frame scheme and below I'm attaching the code which should help you to understand few things if you look at items attached to LOCAL variables. As I said it's not possible to detect real number of local variables in current code. It may change in the future if we store this information in hb_vm[V]Frame() function but now it can be done only indirectly for code compiled for debugger with -b switch catching the messages with names of local variables which are sent to debugger from HVM. > The debugger builds aCallStack calling a c function passi
