Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1136939 - libmono-2.0.so fails to link when built with gcc-4.9.1-7.fc21.s390x
Summary: libmono-2.0.so fails to link when built with gcc-4.9.1-7.fc21.s390x
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: gcc
Version: 21
Hardware: s390x
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: ZedoraTracker
TreeView+ depends on / blocked
 
Reported: 2014-09-03 15:43 UTC by Michal Toman
Modified: 2015-03-23 00:42 UTC (History)
4 users (show)

Fixed In Version: gcc-python-plugin-0.13-3.fc21
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-02-16 03:27:13 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
method-to-ir.i (1.90 MB, text/plain)
2014-09-03 15:57 UTC, Michal Toman
no flags Details


Links
System ID Private Priority Status Summary Last Updated
GNU Compiler Collection 64536 0 None None None 2019-04-11 21:30:06 UTC

Description Michal Toman 2014-09-03 15:43:52 UTC
mono fails to build with gcc-4.9.1-7.fc21 on F21 s390x with the following error:

../mini/.libs/libmono-2.0.so: undefined reference to `.L2527'
collect2: error: ld returned 1 exit status

The problematic file is mono/mini/method-to-ir.c
Adding __attribute__((optimize (0))) to the very last function within the file - mono_spill_global_vars - fixes the problem. Adding __attribute__((optimize (0))) to any other function within the file fixes the build but leads to a segfault when a program tries using the library.

Comment 1 Jakub Jelinek 2014-09-03 15:47:12 UTC
Can you provide preprocessed method-to-ir.i and list what gcc options are used to compile it?  Thanks.

Comment 2 Michal Toman 2014-09-03 15:57:19 UTC
Created attachment 934142 [details]
method-to-ir.i

You are faster than I am :). Attaching method-to-ir.i & the command line used for build:

gcc -DHAVE_CONFIG_H -I. -I../..   -DGC_LINUX_THREADS -D_GNU_SOURCE -D_REENTRANT -DUSE_MMAP -DUSE_MUNMAP  -D__default_codegen__ -DUSE_COMPILER_TLS -I../.. -I../../eglib/src -I../../eglib/src    -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches  -m64 -march=z9-109 -mtune=z10 -fno-strict-aliasing -fno-strict-aliasing -Wdeclaration-after-statement -Wno-unused-but-set-variable -g -Wall -Wunused -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes  -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wno-cast-qual -Wwrite-strings -mbackchain -D__USE_STRING_INLINES -c method-to-ir.c

Comment 3 Jakub Jelinek 2014-09-03 17:21:28 UTC
Can't reproduce this:
./cc1 -quiet -O2 -g -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches  -m64 -march=z9-109 -mtune=z10 -fno-strict-aliasing -mbackchain method-to-ir.i; as -o method-to-ir.{o,s}; nm -u method-to-ir.o | grep L; tail -n 3 method-to-ir.s
	.hidden	mono_defaults
	.ident	"GCC: (GNU) 4.9.1 20140813 (Red Hat 4.9.1-7)"
	.section	.note.GNU-stack,"",@progbits

Comment 4 Dan Horák 2014-09-04 14:16:32 UTC
I think there a very similar problem on i386 building Hercules, which goes away when the cpu.c file is compiled with -O1

...
libtool: link: gcc -shared  -fPIC -DPIC  .libs/hconsole.o .libs/w32util.o .libs/strsignal.o .libs/impl.o .libs/config.o .libs/bldcfg.o .libs/panel.o .libs/history.o .libs/fillfnam.o .libs/ipl.o .libs/assist.o .libs/dat.o .libs/stack.o .libs/cpu.o .libs/vstore.o .libs/general1.o .libs/general2.o .libs/general3.o .libs/pfpo.o .libs/plo.o .libs/control.o .libs/crypto.o .libs/io.o .libs/decimal.o .libs/service.o .libs/scedasd.o .libs/losc.o .libs/chsc.o .libs/opcode.o .libs/diagnose.o .libs/diagmssf.o .libs/vm.o .libs/vmd250.o .libs/channel.o .libs/external.o .libs/float.o .libs/trace.o .libs/machchk.o .libs/vector.o .libs/xstore.o .libs/cmpsc.o .libs/sie.o .libs/qdio.o .libs/clock.o .libs/timer.o .libs/esame.o .libs/ieee.o .libs/dfp.o .libs/httpserv.o .libs/cgibin.o .libs/loadparm.o .libs/hsccmd.o .libs/cmdtab.o .libs/hao.o .libs/hscmisc.o .libs/sr.o .libs/ecpsvm.o   -Wl,-rpath -Wl,/home/dan/hercules/hercules-3.10/.libs -Wl,-rpath -Wl,/home/dan/hercules/hercules-3.10/decNumber/.libs -Wl,-rpath -Wl,/home/dan/hercules/hercules-3.10/softfloat/.libs -L/home/dan/hercules/hercules-3.10/.libs ./.libs/libhercs.so ./.libs/libhercu.so ./.libs/libherct.so ./.libs/libhercd.so /home/dan/hercules/hercules-3.10/.libs/libhercu.so /home/dan/hercules/hercules-3.10/.libs/libhercs.so decNumber/.libs/libdecNumber.so softfloat/.libs/libsoftfloat.so -lltdl -lpthread -lrt -lz -lresolv -lnsl -lm -ldl -lbz2  -O2 -m32 -march=i686 -mtune=atom -O2 -m32 -march=i686 -mtune=atom -Wl,-z -Wl,relro -Wl,--warn-common -pthread -pthread   -pthread -Wl,-soname -Wl,libherc.so -o .libs/libherc.so
/usr/bin/ld: .libs/cpu.o: relocation R_386_GOTOFF against undefined symbol `.L1887' can not be used when making a shared object
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status

I'm working on the details now ...

Comment 5 Michal Toman 2014-09-05 07:43:02 UTC
(In reply to Jakub Jelinek from comment #3)
> Can't reproduce this:
> ./cc1 -quiet -O2 -g -fexceptions -fstack-protector-strong
> --param=ssp-buffer-size=4 -grecord-gcc-switches  -m64 -march=z9-109
> -mtune=z10 -fno-strict-aliasing -mbackchain method-to-ir.i; as -o
> method-to-ir.{o,s}; nm -u method-to-ir.o | grep L; tail -n 3 method-to-ir.s
> 	.hidden	mono_defaults
> 	.ident	"GCC: (GNU) 4.9.1 20140813 (Red Hat 4.9.1-7)"
> 	.section	.note.GNU-stack,"",@progbits

My bad, mono builds two versions - one with -fPIC and one without it and it is actually the -fPIC that makes the difference:

/usr/libexec/gcc/s390x-redhat-linux/4.9.1/cc1 -quiet -O2 -g -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches  -m64 -march=z9-109 -mtune=z10 -fno-strict-aliasing -mbackchain -fPIC method-to-ir.i; nm -u method-to-ir.o | grep L; tail -n 3 method-to-ir.s
                 U .L2527
	.hidden	mono_defaults
	.ident	"GCC: (GNU) 4.9.1 20140813 (Red Hat 4.9.1-7)"
	.section	.note.GNU-stack,"",@progbits

Comment 6 Dan Horák 2014-09-05 10:50:51 UTC
(In reply to Dan Horák from comment #4)
> I think there a very similar problem on i386 building Hercules, which goes
> away when the cpu.c file is compiled with -O1

see bug #1106758 for details

Comment 7 Dan Horák 2014-09-24 15:21:36 UTC
for the record - gcc-4.9.1-9.fc21 doesn't fix this problem

Comment 8 Jakub Jelinek 2014-09-29 15:53:49 UTC
Yes, the fix is not in -10.fc22 either, waiting for Honza to commit it to 4.9.

Comment 9 Jakub Jelinek 2015-01-07 14:09:47 UTC
So, is this still a problem with latest gcc (4.9.2-3.fc2[12])?

Comment 10 Dan Horák 2015-01-07 14:33:26 UTC
(In reply to Jakub Jelinek from comment #9)
> So, is this still a problem with latest gcc (4.9.2-3.fc2[12])?

yes, it is

[sharkcz@devel3 mono]$ /usr/libexec/gcc/s390x-redhat-linux/4.9.2/cc1 -quiet -O2 -g -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches  -m64 -march=z9-109 -mtune=z10 -fno-strict-aliasing -mbackchain -fPIC method-to-ir.i; as -o method-to-ir.{o,s}; nm -u method-to-ir.o | grep L; tail -n 3 method-to-ir.s
                 U .L2534
	.hidden	mono_defaults
	.ident	"GCC: (GNU) 4.9.2 20141217 (Red Hat 4.9.2-3)"
	.section	.note.GNU-stack,"",@progbits

Comment 11 Jakub Jelinek 2015-01-07 16:26:16 UTC
Ok, reproduced with cross-compiler, reducing the testcase now.

Comment 12 Jakub Jelinek 2015-01-08 00:42:50 UTC
Reduced testcase (-O2 -fPIC -m64):
struct { long q; } *h;
long a, b, g, j, k, *c, *d, *e, *f, *i;
long *baz (void);

static inline int
foo (void)
{
  switch (b)
    {
    case 0:
    case 2:
      return a++;
    case 3:
      return a++;
    case 1:
      a++;
    }
  return 0;
}

void
bar (void)
{
  for (;;)
    {
      foo ();
      switch (0)
	{
	case 0:
	  if (d)
	    {
	      f = baz ();
	      g = k++;
	      if (&h->q)
		{
		  j = *f;
		  h->q = *f;
		}
	      else
		i = (long *) (h->q = *f);
	      *c++ = (long) f;
	      e += 6;
	      break;
	    }
	  f = baz ();
	  g = k++;
	  if (&h->q)
	    {
	      j = *f;
	      h->q = *f;
	    }
	  else
	    i = (long *) (h->q = *f);
	  *c++ = (long) f;
	  e += 6;
	}
    }
}

Comment 13 Jakub Jelinek 2015-01-08 10:07:30 UTC
Filed upstream now.

Comment 14 Dan Horák 2015-01-09 22:03:53 UTC
I can confirm mono builds fine with gcc-4.9.2-5.fc21.s390x

Comment 15 Fedora Update System 2015-02-13 12:28:20 UTC
gcc-4.9.2-6.fc21,gcc-python-plugin-0.13-3.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/gcc-4.9.2-6.fc21,gcc-python-plugin-0.13-3.fc21

Comment 16 Fedora Update System 2015-02-15 03:26:46 UTC
Package gcc-python-plugin-0.13-3.fc21, gcc-4.9.2-6.fc21:
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing gcc-python-plugin-0.13-3.fc21 gcc-4.9.2-6.fc21'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-2063/gcc-4.9.2-6.fc21,gcc-python-plugin-0.13-3.fc21
then log in and leave karma (feedback).

Comment 17 Fedora Update System 2015-02-16 03:27:13 UTC
gcc-python-plugin-0.13-3.fc21, gcc-4.9.2-6.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.