Compiler+Decompiler together have a serious 'bad case' bug

Bert Freudenberg bert at impara.de
Mon Jul 24 07:43:34 UTC 2006


Am 24.07.2006 um 09:36 schrieb Marcus Denker:

> On 23.07.2006, at 23:06, Klaus D. Witzel wrote:
>
>> On Sun, 23 Jul 2006 16:52:01 +0200, Marcus Denker  
>> <denker at iam.unibe.ch> wrote:
>>> On 23.07.2006, at 16:31, Bert Freudenberg wrote:
>>>> Am 22.07.2006 um 23:42 schrieb Klaus D. Witzel:
>>>>
>>>>> Strange, why should Decompiler be involved in a halt situation
>>>>
>>>> I guess because there is no method source if you evaluate the code
>>>> in a workspace.
>>
>> Good guess but I found the error in a regular .changes file source  
>> coded method.
>>
>>> Printing of blocks for the stack-trace shown in the pre-debug window
>>> nees the
>>> decompiler...
>>
>> Strange, all source code is available.
>
> Yes... the block-printing uses the decompiler right now, though...  
> but thinking
> about it, it should be possible to use the bc->text mapping (of the  
> encoder)
> to do the printing without decompiling... so printOn: would do
> 	1) compile the method that the block is in to get the MethodNode.
> 	2) get startPC / endPC of the blocks bytecode
> 	3) the MethodNode then has the bc-to-text mapping (MethodNode  
> encoder, I think)
>              that should return the start / end in the text of the  
> method when giving it the bytecode interval
> 	4) print that text in printOn:
>
> Anyone care to try to implement that?

If someone is implementing this, take care to use only the method  
referenced by the block, because the actual method might have changed  
since the block was created.

- Bert -




More information about the Squeak-dev mailing list