User account creation filtered due to spam.

Bug 21016

Summary: Indirect dispatch code generated when using -findirect-dispatch has wrong line numbers
Product: gcc Reporter: Robin Green <greenrd>
Component: javaAssignee: Not yet assigned to anyone <unassigned>
Status: WAITING ---    
Severity: normal CC: gcc-bugs, java-prs
Priority: P2 Keywords: wrong-debug
Version: 4.0.0   
Target Milestone: ---   
Host: Target:
Build: Known to work:
Known to fail: Last reconfirmed: 2012-01-11 00:00:00
Attachments: test case
.java source corresponding to the test case

Description Robin Green 2005-04-14 00:54:58 UTC
(This is superficially similar to bug 16439, in that it involves "synthetic
code" being tagged with insufficiently precise line numbers.)

Compiling the attached .class file with

gcj -findirect-dispatch -shared -S -O0 -g WebappClassLoader.class

results in the following (i386) assembly code for line 1578:

        .loc 1 1578 0
        movl    _CD_org_apache_catalina_loader_WebappClassLoader+200, %eax
        subl    $12, %esp
.LCFI2993:
        pushl   %eax
.LCFI2994:
        call    _Jv_AllocObjectNoFinalizer
        addl    $16, %esp
.LCFI2995:
        movl    %eax, -368(%ebp)
        movl    -368(%ebp), %eax
        movl    %eax, -364(%ebp)
        movl    -364(%ebp), %eax
        movl    %eax, -368(%ebp)
        movl    12(%ebp), %eax
        movl    %eax, -272(%ebp)
        .loc 1 1651 0
        movl    -364(%ebp), %ecx
        movl    _atable_org_apache_catalina_loader_WebappClassLoader+92, %eax
        movl    %eax, %edx
        movl    -272(%ebp), %eax
        subl    $8, %esp
.LCFI2996:
        pushl   %eax
.LCFI2997:
        pushl   %ecx
.LCFI2998:
        call    *%edx
        addl    $16, %esp
.LCFI2999:
        .loc 1 1578 0
        movl    -368(%ebp), %eax
        subl    $12, %esp
.LCFI3000:
        pushl   %eax
.LCFI3001:
        call    _Jv_Throw

Note that while the start and end of this code block is correctly marked as
being from line 1578, the middle (the indirect dispatch) is incorrectly marked
as being from line 1651 (which happens to be the line number of the last
statement in the method.) This causes line numbers in some stack traces to be
incorrect.

Original source file attached below.

# gcj -v
Using built-in specs.
Reading specs from /usr/lib/gcc/i386-redhat-linux/4.0.0/libgcj.spec
rename spec lib to liborig
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-languages=c,c++,objc,java,f95,ada
--enable-java-awt=gtk --host=i386-redhat-linux
Thread model: posix
gcc version 4.0.0 20050405 (Red Hat 4.0.0-0.40)
Comment 1 Robin Green 2005-04-14 01:02:19 UTC
Created attachment 8623 [details]
test case
Comment 2 Robin Green 2005-04-14 01:06:09 UTC
Created attachment 8624 [details]
.java source corresponding to the test case
Comment 3 Richard Biener 2012-01-11 12:57:45 UTC
Is this still an issue?