Re: Small line number problem

[Ondrej LHOTAK <olhotak@sable.mcgill.ca>]

I assume you're talking about bytecode offsets, rather than (source)
line numbers.

The tags in Jimple are assigned to whole *statements*, rather than
individual subexpressions. A Java statement of the form

localVariable = foo.bar();

gets translated to a single Jimple statement. A Java statement of
the form:

myObject.myField = foo.bar();

gets translated to two Jimple statements:

temp = foo.bar();
myObject.myField = temp;

In both cases, the bytecode offset assigned to each Jimple statement is
the offset of the last bytecode corresponding to the Jimple statement.
In the first case, this is the astore, while in the second case, this
is the invoke, because the temp variable is implicit; it doesn't
actually appear in the bytecode.

Now, one could change the definition, and instead if giving the offset
of the *last* bytecode instruction corresponding to a Jimple statement,
we could give the offset of the bytecode instruction that actually does
something interesting (eg invoke, getfield, etc.). This would require
adding the necessary code in soot.coffi.CFG.java. I think it's
worthwhile to do this eventually, but I don't have time before the next
release.

A workaround would be to note that the offset is the offset of the
last bytecode that is part of the Jimple statement, and scan backwards
through the bytecode from that point looking for invoke instructions.

Ondrej


On Mon, Jan 27, 2003 at 12:41:37PM -0000, Eric Bodden wrote:
> Hi!
> 
> I have a small problem with resolving line numbers particular statements
> as e.g.:
> 	variable = toki.hear();
> (an assignment with method call in evaluation part).
> The problem is: If "variable" is a field of the current class, then the
> unit corresponding to this method call will return tne line number of
> this call. But if "variable" is a local variable instead, it will return
> the linenumber of the assignment, which corresponds to the bytecode line
> where "astore" is invoked on the JVM. So I think this is not really
> consistent. Do you know how I could change that (or at least a
> workaround).
> 
> Thanks,
> Eric
> 
> ------------------------------------------------------------
> Eric Bodden
> CS-DIP full time student @ University of Kent at Canterbury
> UKC internal phone: 5095
> ICQ UIN: 12656220, secure mail on demand
> Website: http://www.bodden.de
>