bug: extra four bytes between super/sub instance images, CNI not aware

bug: extra four bytes between super/sub instance images, CNI not aware

[Adam Megacz]

Can somebody confirm that this is a bug? The program below prints out
"0" rather than "3". Closer inspection reveals that foo() is looking
at a memory location four bytes less than wher y is. This behavior
occurs on both Win32 and Linux.

  - a


cat > test.java <<\EOF
abstract class sup {
    long a;
    boolean b;
    public sup() { }
}

public class test {

    public static void main(String[] s) { new inner(); }

    static class inner extends sup {
        int y = 3;
        native void foo();
        inner() { foo(); }
    }

}
EOF

cat > test.cc <<\EOF
#include "test$inner.h"
#include "java/lang/System.h"
#include "java/io/PrintStream.h"

void test$inner::foo() {
    java::lang::System::out->println(y);
}
EOF


jikes test.java
gcjh test\$inner
gcjh sup
CLASSPATH= gcj -I. test.cc test.java -fno-rtti --main=test
./a.out

-- 
The web is dead; long live the Internet.
http://www.xwt.org/

Re: bug: extra four bytes between super/sub instance images, CNI not aware

[Tom Tromey]

>>>>> "Adam" == Adam Megacz <gcj@lists.megacz.com> writes:

Adam> Can somebody confirm that this is a bug? The program below
Adam> prints out "0" rather than "3". Closer inspection reveals that
Adam> foo() is looking at a memory location four bytes less than wher
Adam> y is. This behavior occurs on both Win32 and Linux.

This works for me on Linux.  I'm running a new gcj.

Tom

Re: bug: extra four bytes between super/sub instance images, CNI not aware

[Bryce McKinlay]

Adam Megacz wrote:

>Can somebody confirm that this is a bug? The program below prints out
>"0" rather than "3". Closer inspection reveals that foo() is looking
>at a memory location four bytes less than wher y is. This behavior
>occurs on both Win32 and Linux.
>

I get this too. Is this a regression?

Bryce.

Re: bug: extra four bytes between super/sub instance images, CNI not aware

[Tom Tromey]

>>>>> "Bryce" == Bryce McKinlay <bryce@waitaki.otago.ac.nz> writes:

Adam> Can somebody confirm that this is a bug? The program below
Adam> prints out "0" rather than "3". Closer inspection reveals that
Adam> foo() is looking at a memory location four bytes less than wher
Adam> y is. This behavior occurs on both Win32 and Linux.

Bryce> I get this too. Is this a regression?

I don't know if it is or not.  I want to understand why I don't see
the problem.

Adam, why are you using -fno-rtti?  Bryce, does removing it affect
your results?  (It doesn't for me.)

Do the generated .h files look correct?  Mine do.

Tom

Re: bug: extra four bytes between super/sub instance images, CNI not aware

[Bryce McKinlay]

Tom Tromey wrote:

>>>>>>"Bryce" == Bryce McKinlay <bryce@waitaki.otago.ac.nz> writes:
>>>>>>
>
>Adam> Can somebody confirm that this is a bug? The program below
>Adam> prints out "0" rather than "3". Closer inspection reveals that
>Adam> foo() is looking at a memory location four bytes less than wher
>Adam> y is. This behavior occurs on both Win32 and Linux.
>
>Bryce> I get this too. Is this a regression?
>
>I don't know if it is or not.  I want to understand why I don't see
>the problem.
>

I get it with yesterdays mainline on PowerPC. I haven't tried with 3.1 
or on x86 yet.

>Adam, why are you using -fno-rtti?  Bryce, does removing it affect
>your results?  (It doesn't for me.)
>

No, it makes no difference.

>Do the generated .h files look correct?  Mine do.
>

Yes, they look correct. What seems to be happening is that C++ is 
reading the field "y" at the correct offset by my calculation (20) but 
GCJ is giving "inner" 64-bit alignment within "sup" and thus accessing 
it at the wrong offset (24). Removing the "long" field from sup corrects 
it, so the presence of the long is confusing gcj somehow.

I was suspicious that this might have been caused by my recent alignment 
patch, but reverting that made no difference.

regards

Bryce.

Re: bug: extra four bytes between super/sub instance images, CNI not aware

[Adam Megacz]

Tom Tromey <tromey@redhat.com> writes:
> Adam> Can somebody confirm that this is a bug? The program below
> Adam> prints out "0" rather than "3". Closer inspection reveals that
> Adam> foo() is looking at a memory location four bytes less than wher
> Adam> y is. This behavior occurs on both Win32 and Linux.

> This works for me on Linux.  I'm running a new gcj.

Works == 0 or works == 3?

If it prints '0', it's broken.

 - a

-- 
The web is dead; long live the Internet.
http://www.xwt.org/

Re: bug: extra four bytes between super/sub instance images, CNI not aware

[Adam Megacz]

Bryce McKinlay <bryce@waitaki.otago.ac.nz> writes:
> Is this a regression?

Probably not; I can verify that the bug has been around since at least
January due to the resultant bug in my old XWT builds from that time
period.

It'd still be cool if it got fixed. If it's not the kind of thing
that's likely to get fixed soon, please let me know so I can try to
come up with a workaround.

  - a

-- 
The web is dead; long live the Internet.
http://www.xwt.org/

Re: bug: extra four bytes between super/sub instance images, CNI not aware [java/6393]

[Adam Megacz]

Adam Megacz <gcj@lists.megacz.com> writes:
> Can somebody confirm that this is a bug? The program below prints out
> "0" rather than "3". Closer inspection reveals that foo() is looking
> at a memory location four bytes less than wher y is. This behavior
> occurs on both Win32 and Linux.

This is now PR java/6393

  - a

-- 
The web is dead; long live the Internet.
http://www.xwt.org/

Re: bug: extra four bytes between super/sub instance images, CNI not aware

[Adam Megacz]

Tom Tromey <tromey@redhat.com> writes:
> Adam, why are you using -fno-rtti?

http://gcc.gnu.org/java/faq.html#4_6

But I didn't realize that it's only required for pre-3.0 gcj's until
now.


> Bryce, does removing it affect your results?  (It doesn't for me.)

Same results here too.


> Do the generated .h files look correct?  Mine do.

Yes. The problem is that the Java side of the universe is putting four
empty bytes between the superclass's image and the subclass's
image. All Java-generated code seems to know about this gap, but CNI
code does not.

Could it be that the Java frontend is allocating space for an
enclosing-class pointer even though this is a *static* inner class
(which does not require an enclosing-class pointer)? Removing the
static keyword (and making associated changes) does not fix the bug,
though.

I don't know if we need to adjust gcjh to add the four-byte gap, or
change the Java frontend to remove the gap.

  - a


-- 
The web is dead; long live the Internet.
http://www.xwt.org/

Re: bug: extra four bytes between super/sub instance images, CNI not aware

[Bryce McKinlay]

Adam Megacz wrote:

>I don't know if we need to adjust gcjh to add the four-byte gap, or
>change the Java frontend to remove the gap.
>

I'm pretty sure its a front-end bug.

regards

Bryce.

Re: bug: extra four bytes between super/sub instance images, CNI not aware

[Martin Kahlert]

Hi Adam,

On Sun, Apr 21, 2002 at 07:17:47AM -0700, Adam Megacz wrote:
> 
> Tom Tromey <tromey@redhat.com> writes:
> > Adam> Can somebody confirm that this is a bug? The program below
> > Adam> prints out "0" rather than "3". Closer inspection reveals that
> > Adam> foo() is looking at a memory location four bytes less than wher
> > Adam> y is. This behavior occurs on both Win32 and Linux.
> 
> > This works for me on Linux.  I'm running a new gcj.
> 
> Works == 0 or works == 3?
> 
> If it prints '0', it's broken.

Note: I produced the class files by gcj -C test.java instead of jikes.

$ gcj -v
Reading specs from /sw/gcc-3.1/lib/gcc-lib/i686-pc-linux-gnu/3.1/specs
Reading specs from
/sw/gcc-3.1/lib/gcc-lib/i686-pc-linux-gnu/3.1/../../../libgcj.spec
rename spec lib to liborig
Configured with: ../gcc-20020415/configure --prefix=/sw/gcc-3.1
--enable-languages=f77,c++,java --disable-threads --enable-shared=libstdc++
Thread model: single
gcc version 3.1 20020415 (prerelease)
$ ./a.out 
3

The same on solaris:
$ gcj -v
Reading specs from
/data/titan_1/kahlert/gcc-3.1/lib/gcc-lib/sparcv9-sun-solaris2.7/3.1/specs
Reading specs from
/data/titan_1/kahlert/gcc-3.1/lib/gcc-lib/sparcv9-sun-solaris2.7/3.1/../../../libgcj.spec
rename spec lib to liborig
Configured with: ../gcc-20020415/configure
--prefix=/data/titan_1/kahlert/gcc-3.1 --enable-languages=c++,f77,java
--with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --disable-threads
--disable-shared
Thread model: single
gcc version 3.1 20020415 (prerelease)
$ a.out
0

Hope that helps
Martin.

-- 
The early bird catches the worm. If you want something else for       
breakfast, get up later.

Re: bug: extra four bytes between super/sub instance images, CNI not aware

[Adam Megacz]

Martin Kahlert <martin.kahlert@infineon.com> writes:
> Reading specs from /sw/gcc-3.1/lib/gcc-lib/i686-pc-linux-gnu/3.1/specs
> $ ./a.out 
> 3

> /data/titan_1/kahlert/gcc-3.1/lib/gcc-lib/sparcv9-sun-solaris2.7/3.1/specs
> $ a.out
> 0

That's very, very bizarre -- you're encountering the bug on Solaris2.7
but not on Linux.

  - a

-- 
The web is dead; long live the Internet.
http://www.xwt.org/

Re: bug: extra four bytes between super/sub instance images, CNI not aware

[Bryce McKinlay]

Adam Megacz wrote:

>Martin Kahlert <martin.kahlert@infineon.com> writes:
>
>>Reading specs from /sw/gcc-3.1/lib/gcc-lib/i686-pc-linux-gnu/3.1/specs
>>$ ./a.out 
>>3
>>
>
>>/data/titan_1/kahlert/gcc-3.1/lib/gcc-lib/sparcv9-sun-solaris2.7/3.1/specs
>>$ a.out
>>0
>>
>
>That's very, very bizarre -- you're encountering the bug on Solaris2.7
>but not on Linux.
>

I don't see it on x86 Linux either, it only happens for me on PowerPC. 
Calling debug_tree on the record type node showed "inner" as having 
64-bit alignment within "sup", which is clearly the problem, but I don't 
know where that comes from.

Unfortunatly I can't look at it further right now because my PowerBook 
is in the shop getting fixed!

regards

Bryce.