Debug informations

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Debug informations

Gwenaël Casaccio
Hi,

Right now the only way to get the temps, args names from
methods and blocks is the use the source code and extract
those informations from it.

With the proposed patch I've added for each compiled method/block
a debug information with the args and the names, the class could be
extended to add line number inside it.

Cheers,
Gwen


_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

0001-Add-debug-information.patch (14K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Debug informations

Paolo Bonzini-2
Il 27/05/2013 10:47, Gwenaël Casaccio ha scritto:
> Hi,
>
> Right now the only way to get the temps, args names from
> methods and blocks is the use the source code and extract
> those informations from it.
>
> With the proposed patch I've added for each compiled method/block
> a debug information with the args and the names, the class could be
> extended to add line number inside it.

You can use a single array with arguments and temporaries concatenated.
 Otherwise the patch looks pretty good, thanks!

Paolo

>
> Cheers,
> Gwen
>
>
>
> _______________________________________________
> help-smalltalk mailing list
> [hidden email]
> https://lists.gnu.org/mailman/listinfo/help-smalltalk
>


_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: Debug informations

Gwenaël Casaccio
On 27/05/2013 11:02, Paolo Bonzini wrote:

> Il 27/05/2013 10:47, Gwenaël Casaccio ha scritto:
>> Hi,
>>
>> Right now the only way to get the temps, args names from
>> methods and blocks is the use the source code and extract
>> those informations from it.
>>
>> With the proposed patch I've added for each compiled method/block
>> a debug information with the args and the names, the class could be
>> extended to add line number inside it.
> You can use a single array with arguments and temporaries concatenated.
>   Otherwise the patch looks pretty good, thanks!
>
> Paolo
Here is a new version with one array

>> Cheers,
>> Gwen
>>
>>
>>
>> _______________________________________________
>> help-smalltalk mailing list
>> [hidden email]
>> https://lists.gnu.org/mailman/listinfo/help-smalltalk
>>


_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

debug.patch (21K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Debug informations

Paolo Bonzini-2
Il 27/05/2013 12:26, Gwenaël Casaccio ha scritto:

> On 27/05/2013 11:02, Paolo Bonzini wrote:
>> Il 27/05/2013 10:47, Gwenaël Casaccio ha scritto:
>>> Hi,
>>>
>>> Right now the only way to get the temps, args names from
>>> methods and blocks is the use the source code and extract
>>> those informations from it.
>>>
>>> With the proposed patch I've added for each compiled method/block
>>> a debug information with the args and the names, the class could be
>>> extended to add line number inside it.
>> You can use a single array with arguments and temporaries concatenated.
>>   Otherwise the patch looks pretty good, thanks!
>>
>> Paolo
>
> Here is a new version with one array

Oops, sorry for not noticing this before: this must go in the
MethodInfo, or you break loading old images.  CompiledCode (and
subclasses) have their format set in stone.

Paolo

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: Debug informations

Gwenaël Casaccio
On 27/05/2013 17:15, Paolo Bonzini wrote:

> Il 27/05/2013 12:26, Gwenaël Casaccio ha scritto:
>> On 27/05/2013 11:02, Paolo Bonzini wrote:
>>> Il 27/05/2013 10:47, Gwenaël Casaccio ha scritto:
>>>> Hi,
>>>>
>>>> Right now the only way to get the temps, args names from
>>>> methods and blocks is the use the source code and extract
>>>> those informations from it.
>>>>
>>>> With the proposed patch I've added for each compiled method/block
>>>> a debug information with the args and the names, the class could be
>>>> extended to add line number inside it.
>>> You can use a single array with arguments and temporaries concatenated.
>>>    Otherwise the patch looks pretty good, thanks!
>>>
>>> Paolo
>> Here is a new version with one array
> Oops, sorry for not noticing this before: this must go in the
> MethodInfo, or you break loading old images.  CompiledCode (and
> subclasses) have their format set in stone.
>
> Paolo
Here is the new patch, it does the same but informations are added in
MethodInfo.
I've changed the grow_identity_dic I think that could create a leak (if
the object is
allocated in old space)

Cheers,
Gwen


_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

Add-debug-information-support.patch (17K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Debug informations

Gwenaël Casaccio
On 07/06/2013 15:56, Gwenaël Casaccio wrote:

> On 27/05/2013 17:15, Paolo Bonzini wrote:
>> Il 27/05/2013 12:26, Gwenaël Casaccio ha scritto:
>>> On 27/05/2013 11:02, Paolo Bonzini wrote:
>>>> Il 27/05/2013 10:47, Gwenaël Casaccio ha scritto:
>>>>> Hi,
>>>>>
>>>>> Right now the only way to get the temps, args names from
>>>>> methods and blocks is the use the source code and extract
>>>>> those informations from it.
>>>>>
>>>>> With the proposed patch I've added for each compiled method/block
>>>>> a debug information with the args and the names, the class could be
>>>>> extended to add line number inside it.
>>>> You can use a single array with arguments and temporaries
>>>> concatenated.
>>>>    Otherwise the patch looks pretty good, thanks!
>>>>
>>>> Paolo
>>> Here is a new version with one array
>> Oops, sorry for not noticing this before: this must go in the
>> MethodInfo, or you break loading old images.  CompiledCode (and
>> subclasses) have their format set in stone.
>>
>> Paolo
>
> Here is the new patch, it does the same but informations are added in
> MethodInfo.
> I've changed the grow_identity_dic I think that could create a leak
> (if the object is
> allocated in old space)
>
> Cheers,
> Gwen
>
Sorry but the change for grow_identity_dic was not needed.

Gwen


_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

Add-support-for-DebugInformation.patch (17K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Debug informations

Holger Freyther
On Fri, Jun 07, 2013 at 05:15:15PM +0200, Gwenaël Casaccio wrote:

> -      if (_gst_declare_arguments (method->v_method.selectorExpr) == -1)
> +      if ((argCount = _gst_declare_arguments (method->v_method.selectorExpr)) == -1)

I don't know the GNU style but I find such statements with this kind of
side-effect dangerous.

        argCount = _gst_declare_arguments (method->v_method.selectorExpr);
        if (argCount == -1)
          ....

> +            object->data[0] = _gst_intern_string (args->v_expr.expression->v_list.name);
> +            i = i + 1;

               i += 1; ??


I still need to have a deeper look, but thank you so far.

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: Debug informations

Holger Freyther
In reply to this post by Gwenaël Casaccio
On Fri, Jun 07, 2013 at 05:15:15PM +0200, Gwenaël Casaccio wrote:

Hi,

so my comments from the 8th of May still apply but here is another
round on the same patch.

> +    arguments: anInteger [
> +        <category: 'accessing'>
> +
> +        ^ variables copyFrom: 1 to: anInteger
> +    ]


What is the thought behind not storing these in two different
collections from the beginning?


> diff --git a/libgst/comp.c b/libgst/comp.c
> index 10330e1..b6ce106 100644
> --- a/libgst/comp.c
> +++ b/libgst/comp.c
> @@ -534,6 +534,9 @@ _gst_execute_statements (OOP receiverOOP, memset (&s, 0,

> +      _gst_compiler_state->debugInfo = _gst_identity_dictionary_new (_gst_identity_dictionary_class, 6);
> +      INC_ADD_OOP (_gst_compiler_state->debugInfo);

> @@ -719,6 +726,9 @@ _gst_compile_method (tree_node method,
>    _gst_push_new_scope ();
>    selector = compute_selector (method->v_method.selectorExpr);
>  
> +  _gst_compiler_state->debugInfo = _gst_identity_dictionary_new (_gst_identity_dictionary_class, 6);
> +  INC_ADD_OOP (_gst_compiler_state->debugInfo);


how often will both be created and one of them turns out to be garbage?


> -      if (_gst_declare_arguments (method->v_method.selectorExpr) == -1)
> +      if ((argCount = _gst_declare_arguments (method->v_method.selectorExpr)) == -1)


I have commented this in the previous commit. This is something to get
wrong most of the time and I would prefer to move the assignment out of
the if statement.

> -      if (_gst_declare_temporaries (method->v_method.temporaries) == -1)
> +      if ((tempCount = _gst_declare_temporaries (method->v_method.temporaries)) == -1)

same here.


> +      if (methodOOP != _gst_nil_oop) {
> +        INC_ADD_OOP (methodOOP);
> +
> +        object = new_instance_with (_gst_array_class, argCount + tempCount, &variablesOOP);
> +        INC_ADD_OOP (variablesOOP);
> +
> +        args = method->v_method.selectorExpr;
> +        i = 0;
> +
> +        if (args->nodeType == TREE_BINARY_EXPR)
> +          {
> +            object->data[0] = _gst_intern_string (args->v_expr.expression->v_list.name);
> +            i = i + 1;

use i instead of 0 even if they need to match right now. (and i += 1)


> +
> +        new_instance (_gst_debug_information_class, &debugInfo);
> +        INC_ADD_OOP (debugInfo);
> +
> +        inst_var_at_put (debugInfo, 1, variablesOOP);
> +        _gst_identity_dictionary_at_put (_gst_compiler_state->debugInfo, methodOOP, debugInfo);

the naming of debugInfo for both a dictionary and an instance of the debug
information class is a bit unfortunate. Can you think of two different names?

> +        inst_var_at_put (inst_var_at (methodOOP, 3), 5, _gst_compiler_state->debugInfo);

>      }
>  
>    if (methodOOP != _gst_nil_oop)
>      {
> -      INC_ADD_OOP (methodOOP);

I see that this moved inside into the setjmp block. I know the code too little
to know when EXIT_COMPILATION will be called. What is the guarantee that if
methodOOP != nil that we already INC_ADD_OOPed it?



> +  object = new_instance_with (_gst_array_class, argCount + tempCount, &variablesOOP);
> +  INC_ADD_OOP (variablesOOP);
> +
> +  for (i = 0, args = blockExpr->v_block.arguments; args != NULL; args = args->v_list.next) {
> +    object->data[i] = _gst_intern_string (args->v_list.name);
> +    i = i + 1;

i += 1


>  OOP
> +_gst_identity_dictionary_new (OOP classOOP, int size)
> +{
> +  return identity_dictionary_new (classOOP, size);
> +}
> +
> +OOP
>  identity_dictionary_new (OOP classOOP, int size)

we could just rename it? There are only two callers of it? Either do it now or later
or is there precedence of not doing these renames?


> diff --git a/libgst/files.c b/libgst/files.c
> index a7156f9..913ade1 100644
> --- a/libgst/files.c
> +++ b/libgst/files.c
> @@ -290,6 +290,8 @@ static const char standard_files[] = {
>    "PkgLoader.st\0"
>    "DirPackage.st\0"
>    "Autoload.st\0"
> +
> +  "DebugInformation.st\0"
>  };

oh? that is not too late? I would assume it should be close to
CompiledMethod code?

> +
> +"Test debug informations are generated"
> +Object subclass: Foo [
> +    a_1: i_1 a_2: i_2 [
> +        | i j k |
> +
> +        ^ [ :a :b :c | | d e f | ]
> +    ]
> +]
> +
> +Eval [
> +    | mth |
> +    mth := Foo>>#'a_1:a_2:'.
> +    (mth arguments = #(#'i_1' #'i_2')) printNl.
> +    (mth temporaries =  #(#'i' #'j' #'k')) printNl.
> +    ((mth blockAt: 1) arguments = #(#'a' #'b' #'c')) printNl.
> +    ((mth blockAt: 1) temporaries =  #(#'d' #'e' #'f')) printNl.
> +    nil


*yeah* !!!

One more question. Paolo had a comment in regard to compat with older
images. I forgot the details, do you remember them? Did you already
include his comment?

holger

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: Debug informations

Gwenaël Casaccio
Thanks for the review :-)

You can find the new (and hope last) version of the patch!

On 23/06/2013 20:16, Holger Hans Peter Freyther wrote:

> On Fri, Jun 07, 2013 at 05:15:15PM +0200, Gwenaël Casaccio wrote:
>
> Hi,
>
> so my comments from the 8th of May still apply but here is another
> round on the same patch.
>
>> +    arguments: anInteger [
>> +        <category: 'accessing'>
>> +
>> +        ^ variables copyFrom: 1 to: anInteger
>> +    ]
> What is the thought behind not storing these in two different
> collections from the beginning?
I think it produces smaller images

>
>> diff --git a/libgst/comp.c b/libgst/comp.c
>> index 10330e1..b6ce106 100644
>> --- a/libgst/comp.c
>> +++ b/libgst/comp.c
>> @@ -534,6 +534,9 @@ _gst_execute_statements (OOP receiverOOP, memset (&s, 0,
>> +      _gst_compiler_state->debugInfo = _gst_identity_dictionary_new (_gst_identity_dictionary_class, 6);
>> +      INC_ADD_OOP (_gst_compiler_state->debugInfo);
>> @@ -719,6 +726,9 @@ _gst_compile_method (tree_node method,
>>     _gst_push_new_scope ();
>>     selector = compute_selector (method->v_method.selectorExpr);
>>  
>> +  _gst_compiler_state->debugInfo = _gst_identity_dictionary_new (_gst_identity_dictionary_class, 6);
>> +  INC_ADD_OOP (_gst_compiler_state->debugInfo);
> how often will both be created and one of them turns out to be garbage?
a new object can be created when items will be added in the dictionary
(ie when it grows), also
I thing it's nice to protect object to be GC'ed for a future usage (at
least in the compiler).

>> -      if (_gst_declare_arguments (method->v_method.selectorExpr) == -1)
>> +      if ((argCount = _gst_declare_arguments (method->v_method.selectorExpr)) == -1)
> I have commented this in the previous commit. This is something to get
> wrong most of the time and I would prefer to move the assignment out of
> the if statement.
>
>> -      if (_gst_declare_temporaries (method->v_method.temporaries) == -1)
>> +      if ((tempCount = _gst_declare_temporaries (method->v_method.temporaries)) == -1)
> same here.

Fixed

>
>> +      if (methodOOP != _gst_nil_oop) {
>> +        INC_ADD_OOP (methodOOP);
>> +
>> +        object = new_instance_with (_gst_array_class, argCount + tempCount, &variablesOOP);
>> +        INC_ADD_OOP (variablesOOP);
>> +
>> +        args = method->v_method.selectorExpr;
>> +        i = 0;
>> +
>> +        if (args->nodeType == TREE_BINARY_EXPR)
>> +          {
>> +            object->data[0] = _gst_intern_string (args->v_expr.expression->v_list.name);
>> +            i = i + 1;
> use i instead of 0 even if they need to match right now. (and i += 1)
Fixed

>> +
>> +        new_instance (_gst_debug_information_class, &debugInfo);
>> +        INC_ADD_OOP (debugInfo);
>> +
>> +        inst_var_at_put (debugInfo, 1, variablesOOP);
>> +        _gst_identity_dictionary_at_put (_gst_compiler_state->debugInfo, methodOOP, debugInfo);
> the naming of debugInfo for both a dictionary and an instance of the debug
> information class is a bit unfortunate. Can you think of two different names?

it's renamed as debugInfoDict

>> +        inst_var_at_put (inst_var_at (methodOOP, 3), 5, _gst_compiler_state->debugInfo);
>>       }
>>  
>>     if (methodOOP != _gst_nil_oop)
>>       {
>> -      INC_ADD_OOP (methodOOP);
> I see that this moved inside into the setjmp block. I know the code too little
> to know when EXIT_COMPILATION will be called. What is the guarantee that if
> methodOOP != nil that we already INC_ADD_OOPed it?

If there is an error the compiler will return nil thus all the object
could be GC'ed
that's not a problem.

>
>
>> +  object = new_instance_with (_gst_array_class, argCount + tempCount, &variablesOOP);
>> +  INC_ADD_OOP (variablesOOP);
>> +
>> +  for (i = 0, args = blockExpr->v_block.arguments; args != NULL; args = args->v_list.next) {
>> +    object->data[i] = _gst_intern_string (args->v_list.name);
>> +    i = i + 1;
> i += 1
>
>
>>   OOP
>> +_gst_identity_dictionary_new (OOP classOOP, int size)
>> +{
>> +  return identity_dictionary_new (classOOP, size);
>> +}
>> +
>> +OOP
>>   identity_dictionary_new (OOP classOOP, int size)
> we could just rename it? There are only two callers of it? Either do it now or later
> or is there precedence of not doing these renames?
It's renamed

>> diff --git a/libgst/files.c b/libgst/files.c
>> index a7156f9..913ade1 100644
>> --- a/libgst/files.c
>> +++ b/libgst/files.c
>> @@ -290,6 +290,8 @@ static const char standard_files[] = {
>>     "PkgLoader.st\0"
>>     "DirPackage.st\0"
>>     "Autoload.st\0"
>> +
>> +  "DebugInformation.st\0"
>>   };
> oh? that is not too late? I would assume it should be close to
> CompiledMethod code?
Done

>> +
>> +"Test debug informations are generated"
>> +Object subclass: Foo [
>> +    a_1: i_1 a_2: i_2 [
>> +        | i j k |
>> +
>> +        ^ [ :a :b :c | | d e f | ]
>> +    ]
>> +]
>> +
>> +Eval [
>> +    | mth |
>> +    mth := Foo>>#'a_1:a_2:'.
>> +    (mth arguments = #(#'i_1' #'i_2')) printNl.
>> +    (mth temporaries =  #(#'i' #'j' #'k')) printNl.
>> +    ((mth blockAt: 1) arguments = #(#'a' #'b' #'c')) printNl.
>> +    ((mth blockAt: 1) temporaries =  #(#'d' #'e' #'f')) printNl.
>> +    nil
> *yeah* !!!
:-D
> One more question. Paolo had a comment in regard to compat with older
> images. I forgot the details, do you remember them? Did you already
> include his comment?
The format of the compiled method shouldn't changed, I keep the same format
I only change the MethodInfo class.

> holger

Gwen

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

0001-Add-support-for-DebugInformation-final.patch (18K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Debug informations

Holger Freyther
In reply to this post by Holger Freyther
On Sun, Jun 23, 2013 at 08:16:17PM +0200, Holger Hans Peter Freyther wrote:
> On Fri, Jun 07, 2013 at 05:15:15PM +0200, Gwenaël Casaccio wrote:

Hi,

I tried to integrate your change but travis-ci is spotting something
fishy. During make distcheck (not the make check in the workdir build)
the FractionANSITest is failing. I am attaching the output from the
testsuite.log.

Paolo do you have an idea of what go wrong? I have no explanation/
hypothesis of where the difference between check/distcheck is. This
is not a JIT build. :)


70. testsuite.at:106: testing FractionANSITest ...
{ (cd /home/travis/build/zecke/gnu-smalltalk-debian/smalltalk-3.2.91/_build && timeout 600s gst -I /home/travis/build/zecke/gnu-smalltalk-debian/smalltalk-3.2.91/_build/tests/gst.im -f /home/travis/build/zecke/gnu-smalltalk-debian/smalltalk-3.2.91/_build/../tests/AnsiRun.st FractionANSITest); echo exit 0 > retcode; } | tr -d '\r' | tee stdout; . ./retcode
../../tests/testsuite.at:106: { (cd $abs_top_builddir && $TIMEOUT gst $image_path -f $abs_srcdir/AnsiRun.st FractionANSITest); echo exit $? > retcode; } | tr -d '\r' | tee stdout; . ./retcode
stdout:
did not understand #value:
TestCondensedLog(TestVerboseLog)>>logError: (SUnit.star#VFS.ZipFile/SUnit.st:608)
TestCondensedLog>>logError: (SUnit.star#VFS.ZipFile/SUnit.st:668)
FractionANSITest(TestCase)>>logError: (SUnit.star#VFS.ZipFile/SUnit.st:877)
[] in TestResult>>runCase: (SUnit.star#VFS.ZipFile/SUnit.st:443)
MessageNotUnderstood(Exception)>>activateHandler: (ExcHandling.st:515)
MessageNotUnderstood(Exception)>>pass (ExcHandling.st:385)
optimized [] in MainTestCase>>runCase (../tests/Ansi.st:5225)
MessageNotUnderstood(Exception)>>activateHandler: (ExcHandling.st:515)
MessageNotUnderstood(Exception)>>signal (ExcHandling.st:254)
String(Object)>>doesNotUnderstand: #value: (../tests/AnsiLoad.st:65)
[] in Interval(Iterable)>>allSatisfy: (Iterable.st:153)
Interval>>do: (Interval.st:95)
Interval(Iterable)>>allSatisfy: (Iterable.st:153)
[] in FractionANSITest>>testXtoX (../tests/Ansi.st:2737)
FractionANSITest(TestCaseProtocol)>>value:should:conformTo:selector: (../tests/Ansi.st:5336)
[] in FractionANSITest>>testXtoX (../tests/Ansi.st:2740)
Array(SequenceableCollection)>>do: (SeqCollect.st:826)
FractionANSITest>>testXtoX (../tests/Ansi.st:2730)
optimized [] in MainTestCase>>runCase (../tests/Ansi.st:5222)
BlockClosure>>on:do: (BlkClosure.st:193)
FractionANSITest(MainTestCase)>>runCase (../tests/Ansi.st:5223)
[] in TestResult>>runCase: (SUnit.star#VFS.ZipFile/SUnit.st:434)
BlockClosure>>on:do: (BlkClosure.st:193)
BlockClosure>>sunitOn:do: (SUnit.star#VFS.ZipFile/SUnitPreload.st:94)
[] in TestResult>>runCase: (SUnit.star#VFS.ZipFile/SUnit.st:435)



_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk