[Bug target/32462] [4.3 regression] Linking libgcj.so fails on Solaris 10/x86
--- Comment #17 from ro at gcc dot gnu dot org 2007-07-16 17:07 --- Subject: Bug 32462 Author: ro Date: Mon Jul 16 17:07:25 2007 New Revision: 126684 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126684 Log: PR target/32462 PR libgcj/32465 * class.c (hide): Wrap in HAVE_GAS_HIDDEN. Modified: trunk/gcc/java/ChangeLog trunk/gcc/java/class.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32462
[Bug target/32462] [4.3 regression] Linking libgcj.so fails on Solaris 10/x86
--- Comment #18 from ro at gcc dot gnu dot org 2007-07-16 17:09 --- Fixed for 4.3. -- ro at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32462
[Bug target/32462] [4.3 regression] Linking libgcj.so fails on Solaris 10/x86
--- Comment #8 from ro at gcc dot gnu dot org 2007-07-12 10:18 --- I've now identified the patch that caused this regression: 2007-04-03 Andrew Haley [EMAIL PROTECTED] * jvgenmain.c (main): Change main to use class$, not class$$. (do_mangle_classname): Likewise. * class.c (hide): New function. (add_field): Hide everything that shouldn't be visible outside a DSO. (build_static_class_ref): Likewise. (build_classdollar_field): Likewise. (make_class_data): Likewise. (layout_class_method): Likewise. * expr.c (special_method_p): New function. * class.c (push_class): Don't bogusly guess the source filename. * jcf-parse.c (give_name_to_class): Don't set input_location from DECL_ARTIFICIAL decls. The problem is that it assumes that the platform has support for the visibility attribute, which is not true if using /usr/sfw/bin/gas (2.15) with Sun ld. While it would work on Solaris 10, it might require linker patches on older releases and is probably hard to detect via autoconf. During the build, there are many warnings /mnt/gcc-reghunt/libjava/java/lang/Class.java:1379: warning: visibility attribute not supported in this configuration; ignored but I hadn't seen the connection before. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32462
[Bug target/32462] [4.3 regression] Linking libgcj.so fails on Solaris 10/x86
--- Comment #9 from aph at gcc dot gnu dot org 2007-07-12 10:49 ---
This is somewhat bewildering: if the visibility attribute is not supported, who
does setting the visibility make any difference to the build?
Nonetheless, I have no objection to something like
static void
hide (tree decl)
{
#ifdef __linux__
DECL_VISIBILITY (decl) = VISIBILITY_HIDDEN;
DECL_VISIBILITY_SPECIFIED (decl) = 1;
#endif
}
or whatever macro seems appropriate to you, in order to restrict this to
GNU/Linux systems.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32462
[Bug target/32462] [4.3 regression] Linking libgcj.so fails on Solaris 10/x86
--- Comment #10 from ro at techfak dot uni-bielefeld dot de 2007-07-12
14:15 ---
Subject: Re: [4.3 regression] Linking libgcj.so fails on Solaris 10/x86
aph at gcc dot gnu dot org writes:
--- Comment #9 from aph at gcc dot gnu dot org 2007-07-12 10:49 ---
This is somewhat bewildering: if the visibility attribute is not supported,
who
does setting the visibility make any difference to the build?
I have no idea (and haven't really checked).
Nonetheless, I have no objection to something like
static void
hide (tree decl)
{
#ifdef __linux__
DECL_VISIBILITY (decl) = VISIBILITY_HIDDEN;
DECL_VISIBILITY_SPECIFIED (decl) = 1;
#endif
}
or whatever macro seems appropriate to you, in order to restrict this to
GNU/Linux systems.
I think the following variant should be ok. I added it to the previously
failing revision (with only c, c++, and java), and now both 32 and 64 bit
libgcj.so build.
2007-07-12 Andrew Haley [EMAIL PROTECTED]
Rainer Orth [EMAIL PROTECTED]
PR target/32462
PR libgcj/32465
* class.c (hide): Wrap in HAVE_GAS_HIDDEN.
diff -r e4a0b686f36f gcc/java/class.c
--- a/gcc/java/class.c Tue Apr 03 15:28:16 2007 +
+++ b/gcc/java/class.c Thu Jul 12 15:04:11 2007 +0200
@@ -691,10 +691,12 @@ build_java_method_type (tree fntype, tre
}
static void
-hide (tree decl)
-{
+hide (tree decl ATTRIBUTE_UNUSED)
+{
+#ifdef HAVE_GAS_HIDDEN
DECL_VISIBILITY (decl) = VISIBILITY_HIDDEN;
DECL_VISIBILITY_SPECIFIED (decl) = 1;
+#endif
}
tree
Is this enough for checkin or should I run a full mainline bootstrap? At
least it fixes two bootstrap failures.
Rainer
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32462
[Bug target/32462] [4.3 regression] Linking libgcj.so fails on Solaris 10/x86
--- Comment #11 from ro at gcc dot gnu dot org 2007-07-12 14:26 --- Mine. -- ro at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ro at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-12 14:26:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32462
[Bug target/32462] [4.3 regression] Linking libgcj.so fails on Solaris 10/x86
--- Comment #12 from aph at gcc dot gnu dot org 2007-07-12 14:34 --- You should probably bootstrap. Post the patch to the list. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32462
[Bug target/32462] [4.3 regression] Linking libgcj.so fails on Solaris 10/x86
--- Comment #13 from pinskia at gmail dot com 2007-07-12 15:47 ---
Subject: Re: [4.3 regression] Linking libgcj.so fails on Solaris 10/x86
On 12 Jul 2007 14:15:06 -, ro at techfak dot uni-bielefeld dot de
[EMAIL PROTECTED] wrote:
static void
-hide (tree decl)
-{
+hide (tree decl ATTRIBUTE_UNUSED)
+{
+#ifdef HAVE_GAS_HIDDEN
DECL_VISIBILITY (decl) = VISIBILITY_HIDDEN;
DECL_VISIBILITY_SPECIFIED (decl) = 1;
+#endif
}
This is way too conservative, see PR 26989 for the reasons why?
Thanks,
Andrew Pinski
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32462
[Bug target/32462] [4.3 regression] Linking libgcj.so fails on Solaris 10/x86
--- Comment #14 from ro at techfak dot uni-bielefeld dot de 2007-07-12 17:16 --- Subject: Re: [4.3 regression] Linking libgcj.so fails on Solaris 10/x86 pinskia at gmail dot com writes: This is way too conservative, see PR 26989 for the reasons why? But how do you propose to handle this? In Comment #4 of this PR, you state that there's currently no way to check this. AFAICT, the only platform not handled by HAVE_GAS_HIDDEN is darwin, which I don't have access to. At worst, I could add #if defined(HAVE_GAS_HIDDEN) || (defined(__MACH__) defined(__APPLE__)) Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32462
[Bug target/32462] [4.3 regression] Linking libgcj.so fails on Solaris 10/x86
--- Comment #15 from aph at gcc dot gnu dot org 2007-07-12 17:27 --- #ifdef HAVE_GAS_HIDDEN is fine. There is no real bad consequence to not hiding those symbols; it's just that the DSO exports a lot of unnecessary junk. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32462
[Bug target/32462] [4.3 regression] Linking libgcj.so fails on Solaris 10/x86
--- Comment #16 from ro at techfak dot uni-bielefeld dot de 2007-07-12 17:30 --- Subject: Re: [4.3 regression] Linking libgcj.so fails on Solaris 10/x86 aph at gcc dot gnu dot org writes: #ifdef HAVE_GAS_HIDDEN is fine. There is no real bad consequence to not hiding those symbols; it's just that the DSO exports a lot of unnecessary junk. Ok, thanks. The full bootstrap (all languages) is in progress, but the previous ones already confirmed that libgcj.so links which it didn't before. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32462
[Bug target/32462] [4.3 regression] Linking libgcj.so fails on Solaris 10/x86
--- Comment #6 from aph at gcc dot gnu dot org 2007-07-09 10:36 --- _ZN4java4lang12PosixProcess9queueLockE is defined in the assembly source: .globl _ZN4java4lang12PosixProcess9queueLockE .bss .align 4 .type _ZN4java4lang12PosixProcess9queueLockE, @object .size _ZN4java4lang12PosixProcess9queueLockE, 4 _ZN4java4lang12PosixProcess9queueLockE: .zero 4 So, the question is why the linker is complaining that a GOT relative relocation must reference a local symbol since it is defined locally and it should be possible to calculate its offset from the GOT. -- aph at gcc dot gnu dot org changed: What|Removed |Added CC||aph at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32462
[Bug target/32462] [4.3 regression] Linking libgcj.so fails on Solaris 10/x86
--- Comment #7 from ro at techfak dot uni-bielefeld dot de 2007-07-09 17:48 --- Subject: Re: [4.3 regression] Linking libgcj.so fails on Solaris 10/x86 aph at gcc dot gnu dot org writes: So, the question is why the linker is complaining that a GOT relative relocation must reference a local symbol since it is defined locally and it should be possible to calculate its offset from the GOT. I've looked up the message in the OpenSolaris ld sources: they are from http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/sgs/libld/common/relocate.c (ld_process_sym_reloc), l. 1187 - 1198 (the message is MSG_REL_BADGOTBASED). On l. 1116.. there's a description of which symbols are considered local. I must confess that I don't fully understand what is going on there ;-) Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32462
[Bug target/32462] [4.3 regression] Linking libgcj.so fails on Solaris 10/x86
--- Comment #3 from ro at gcc dot gnu dot org 2007-07-03 17:55 --- Created an attachment (id=13837) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13837action=view) process-Posix.s built with gcj 4.2.1 20070611 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32462
[Bug target/32462] [4.3 regression] Linking libgcj.so fails on Solaris 10/x86
--- Comment #4 from ro at gcc dot gnu dot org 2007-07-03 17:56 --- Created an attachment (id=13838) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13838action=view) process-Posix.s built with gcj 4.3.0 20070618 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32462
[Bug target/32462] [4.3 regression] Linking libgcj.so fails on Solaris 10/x86
--- Comment #5 from ro at techfak dot uni-bielefeld dot de 2007-07-03 17:57 --- Subject: Re: [4.3 regression] Linking libgcj.so fails on Solaris 10/x86 I compared the assembler files corresponding to java/.libs/process-Posix.o and built with both gcj 4.2.1 20070611 and 4.3.0 20070618 and compared the results: the primary differences are like this: @@ -1886,9 +2012,8 @@ movl%eax, %esi movl%eax, (%esp) call[EMAIL PROTECTED] - movl[EMAIL PROTECTED](%ebx), %eax - movl%esi, (%eax) -.LBE57: + movl%esi, [EMAIL PROTECTED](%ebx) +.LBE60: movl4(%esp), %ebx movl8(%esp), %esi addl$12, %esp I've uploaded both files for further inspection. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32462
[Bug target/32462] [4.3 regression] Linking libgcj.so fails on Solaris 10/x86
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Keywords||build Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32462
[Bug target/32462] [4.3 regression] Linking libgcj.so fails on Solaris 10/x86
--- Comment #2 from ro at gcc dot gnu dot org 2007-06-29 18:26 --- Correction: this is a regression in 4.3. -- ro at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.2 regression] Linking|[4.3 regression] Linking |libgcj.so fails on Solaris |libgcj.so fails on Solaris |10/x86 |10/x86 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32462
