Re: Linenumber bug?

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

I believe the JVM Spec says something about a line number attribute
applying to all bytecodes that come after it, up until the next line
number attribute (to keep the line number table small). I don't know
what the rules are in Jimple, but it appears to attach line number tags
to each Jimple instruction, so multiple instructions with the same line
number each have their own tag. In your case, it doesn't do this.

Does anyone know what the rules are for line number tags in Jimple? Are
they even specified anywhere? For what purpose were the line number tags
originally added to Soot, and when?

Ondrej

On Mon, Sep 08, 2003 at 10:00:12PM +0100, Eric Bodden wrote:
> Ok, I got this problem tracked down further. I think, I missintepreted some
> things. You are right: It is not related to the call graph analysis.
> 
> However there are some problems which I am not quite soure where they origin
> from: A snipped from the Jimple looks like this:
> 
>     void foo()
>     {
> ...
>         r3 = $r4;
> 25
>         virtualinvoke r3.<A: java.lang.String m()>();
>         return;
> 27
>     }
> 
> As you can see, for some reason the virtualinvoke statement has no line
> number attached. However this seems not to be a SOOT problem but rather a
> bytecode problem because javap gives me the following for this method:
> 
> Method void foo()
> ...
>   16 aload_2
>   17 invokevirtual #24 <Method java.lang.String m()>
>   20 pop
>   21 return
> 
> Line numbers for method void foo()
>    line 24: 0
>    line 25: 8
>    line 26: 16
>    line 27: 21
> 
> So also here: No line number for the virtual invoke - for some reason.
> Probably I should mention that the object, the method is invoked on, is a
> local variable.
> 
> So in general: Do you think there is a workaround to retrieve a linenumber
> or at least an approximation for such a statenment?
> 
> Thank you very much,
> 
> Eric
>