2011/8/24 Nicolas Cellier <[email protected]>: > So the entries of interest for highlighting are > > Debugger>>contentsSelection > Debugger>>pcRange > CompiledMethod>>debuggerMap > DebuggerMethodMap class>>forMethod: > DebuggerMethodMap>>rangeForPC:contextIsActiveContext: > > Then you see the DebuggerMethodMap>>forMethod:methodNode: takes both a > CompiledMethod and its #methodNode. > CompiledMethod>>methodNode invokes the Parser to get the > AbstractSyntaxTree from method source, and if it ever fails ends up by > trying to decompile the byteCodes. > > This is the easy part. Now we to deal with #abstractPCForConcretePC: > and #abstractSourceMap. > > By reading CompiledMethod>>abstractPCForConcretePC: you should quickly > understand that a concrete PC is a byte offset of current byteCode > (the offsets displayed in the byteCode view) while the abstractPC is > just the rank of current byteCode in the list of byteCodes > instructions composing the CompiledMethod. This is just because > "byteCodes" may spread on several bytes beside their name... > This will use InstructionStream and InstructionClient which are just > an iterator and a sort of visitor on byteCode instructions. > So this is not really interesting. > > The more interesting part is #abstractSourceMap > There is a first step to obtain CompiledMethod>>rawSourceRangesAndMethodDo: > This is the most important part. > The rest is again a mapping from concretePC (instruction byte offset) > to abstractPC (instruction rank). > And some build of a dictionary mapping instruction rank (abstractPC) > -> selected range. > > Note that the last trick seems to use a regenerated CompiledMethod > (theMethodToScan) rather than the original CompiledMethod. There is no > assertion whether these two are equivalent or not. A priori, they > should, unless the Compiler changed since last compilation or if its > behaviour is affected by some Preferences... Would we introduce some > customizable Compiler optimizations that this could become a problem > (We would then add to map decompiled AST to source code AST, probably > with guesses, unless the CompiledMethod would contain debugger > friendly hints...) > We will consider this is not a problem by now. > > So let's now concentrate on rawSourceRangesAndMethodDo: > The nice thing is that you now can just debug this > > (ClosureTests>>#testToDoOutsideTemp) methodNode > rawSourceRangesAndMethodDo: [:rs :mth | ] > > and see how it goes in Squeak. I did not look in Pharo yet, but I > would be amazed to see it much different. > It's now late, and my spare time is off, but you have clues to get > more insights. I wish you good debugging, and come back to me if it > ever goes in deeper complications. > > Cheers > > Nicolas >
Oh, I couldn't resist and just tried, and it's indeed getting harder, because it involves a zoo of Compiler internals, at least the Encoder, the BlockAnalyzer... Funny, the method node is once more generated in this phase :). All this stuff is cached at upper level, but we have at least clues for further optimizations ;) Nicolas > 2011/8/24 Michael Roberts <[email protected]>: >> >>> >>> Ok I'm curious to know then. >> >> Here is a little trace from this example method: >> >> toDoOutsideTemp >> | temp collection | >> collection := OrderedCollection new. >> 1 to: 5 do: [ :index | >> temp := index. >> collection add: [ temp ] ] >> >> Trace is start,stop position of the highlight for each 'step over'. >> >> Whilst the numbers are hard to visualise, below you can see how they >> slightly diverge. >> Left Pharo Right Squeak >> >> 50, 73 71, 73 diff >> 71, 73 71, 73 >> 50, 73 50, 73 >> 108, 115 79, 121 diff >> 79, 121 79, 121 >> 108, 115 108, 115 >> 132, 144 132, 144 >> 147, 146 146, 146 (diff negative size means no highlight) >> 146, 146 146, 146 >> 79, 121 79, 121 >> 108, 115 108, 115 >> 132, 144 132, 144 >> 147, 146 146, 146 >> 146, 146 146, 146 >> 79, 121 79, 121 >> 108, 115 108, 115 >> 132, 144 132, 144 >> 147, 146 146, 146 >> 146, 146 146, 146 >> 79, 121 79, 121 >> 108, 115 108, 115 >> etc... >> For example the first difference is because Pharo shows the whole assignment >> of the first line as the first send, even though it is not. >> The second difference is that Pharo shows the assignment inside the block as >> the first highlight of the loop even though the to:do should be >> highlighted....but both Pharo & Squeak get the to:do: wrong when they choose >> to show it. >> hope you get the idea... >> Mike >
