Bug 398 - elf/dl-runtime.c not resolving CFI_STARTPROC
Summary: elf/dl-runtime.c not resolving CFI_STARTPROC
Status: RESOLVED WONTFIX
Alias: None
Product: glibc
Classification: Unclassified
Component: libc (show other bugs)
Version: 2.3.3
: P2 normal
Target Milestone: ---
Assignee: GOTO Masanori
URL:
Keywords:
Depends on:
Blocks: libc237
  Show dependency treegraph
 
Reported: 2004-09-23 00:03 UTC by Mark Post
Modified: 2014-05-28 19:43 UTC (History)
2 users (show)

See Also:
Host: s390-slackware-linux
Target: s390-slackware-linux
Build: s390-slackware-linux
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Post 2004-09-23 00:03:51 UTC
Configure command:
# CFLAGS="-g -O3" ../configure --prefix=/usr
--enable-add-ons=libidn,linuxthreads   --without-cvs s390-slackware-linux

# gcc -v
Reading specs from /usr/lib/gcc-lib/s390-slackware-linux/3.3.4/specs
Configured with: ../gcc-3.3.4/configure --prefix=/usr --enable-shared
--enable-threads=posix --enable-__cxa_atexit --disable-checking --with-gnu-ld
--verbose --target=s390-slackware-linux --host=s390-slackware-linux
Thread model: posix
gcc version 3.3.4

# ld -v
GNU ld version 2.15.90.0.3 20040415

# /lib/libc.so.6
GNU C Library stable release version 2.3.2, by Roland McGrath et al.
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 3.3.4.
Compiled on a Linux 2.4.26 system on 2004-09-09.
Available extensions:
        GNU libio by Per Bothner
        crypt add-on version 2.1 by Michael Glad and others
        linuxthreads-0.10 by Xavier Leroy
        BIND-8.2.3-T5B
        libthread_db work sponsored by Alpha Processor Inc
        NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
Report bugs using the `glibcbug' script to <bugs@gnu.org>.



I am trying to compile glibc-2.3.3-200408040157 on Linux/390.  When I do, I get
a compilation error in elf/dl-runtime.c, as follows:
dl-runtime.c:222: error: parse error before "CFI_STARTPROC"

I was able to get it to compile by adding
#include <sysdeps.h>

to the source, but I would have thought that was already being included
somewhere by something or other.  Examining the output from --save-temps shows
that it is not.  When I add in the include, I can then see all these other
includes happening:
# 27 "dl-runtime.c" 2
# 1 "../sysdeps/unix/sysv/linux/s390/s390-32/sysdep.h" 1
# 23 "../sysdeps/unix/sysv/linux/s390/s390-32/sysdep.h"
# 1 "../sysdeps/s390/s390-32/sysdep.h" 1
# 21 "../sysdeps/s390/s390-32/sysdep.h"
# 1 "../sysdeps/generic/sysdep.h" 1
# 22 "../sysdeps/s390/s390-32/sysdep.h" 2
# 24 "../sysdeps/unix/sysv/linux/s390/s390-32/sysdep.h" 2
and the compile completes fine.

I have no idea why I would be the first one to encounter this, since the code is
over 6 months old, but apparently the problem doesn't show up on Intel.
Comment 1 Roland McGrath 2004-09-23 02:22:14 UTC

*** This bug has been marked as a duplicate of 333 ***
Comment 2 Mark Post 2004-09-23 04:26:50 UTC
I just read Bug # 333.  I particularly liked the comment "Reports about build
issues of any kind do not belong in bugzilla."  Just what the devil is bugzilla
for, then?  An exercise in futility?

I also thought that "If you have bona fide issues and fixes for them, we welcome
your direct participation in glibc development by using the public development
mailing lists.  Any bona fide build issue is a platform-specific problem on a
platform whose maintainer has not updated the code recently, or whose build
environment does not have the same problems you encountered." was particularly
self-serving.  Since I am the platform maintainer, where does that leave me?  As
a distribution maintainer, I expect people to take bug reports via their
preferred bug reporting mechanism and _fix_ them, not tell the bug reporter that
they were an idiot for using the bug reporting mechanism.  If you don't want bug
reports, why don't you just shut down the bugzilla page?
Comment 3 Ulrich Drepper 2004-09-26 12:46:44 UTC
We will not fix bugs for you.  Every build failure you have is your own fault. 
Bugzilla is for code bugs and not your inability to build binaries.

*** This bug has been marked as a duplicate of 333 ***
Comment 4 Mark Post 2004-09-26 16:00:05 UTC
Well, let's see.  I've been building glibc for 4 years now, with few problems. 
The problems I had were S/390-specific CODE BUGS, not my "inability to build
binaries."  I know that this is also a CODE BUG because changing the BUGGY CODE
allows it to build properly and work.  (Sensing any kind of theme here?)

You don't want to debug people's bad build environments for them.  That's fine,
and I can understand it.  I don't want debug a developer's BUGGY CODE for them.
 Hopefully you can understand that.  Based on your total unwillingness to admit
that there could ever be a code bug, I have my doubts you ever can understand
that.  I don't have a bad build environment.  Can we all say that together?  I
don't have a bad build environment.  It builds all sorts of glibc binaries just
fine.  But not 2.3.3--200408040157 on Linux/390, unless I add one stinking
#include to the BUGGY CODE.

Comment 5 Jakub Jelinek 2004-09-26 16:16:08 UTC
So why are you trying to build that old snapshot?
We build CVS glibc on s390 every few days, last known to work glibc on s390
is CVS snapshot from this morning.
Bugs in old snapshots certainly can't be retroactively fixed, it would be fixed
in current CVS.  But current CVS is known to work.



*** This bug has been marked as a duplicate of 333 ***
Comment 6 Mark Post 2004-09-26 18:03:18 UTC
Because later versions break when including TLS support, and we want/need that.
 I tried a current CVS pull from 12:00 ET, and indeed, when trying to build
dl-reloc,  I get this error:
dl-reloc.c: In function `_dl_allocate_static_tls':
dl-reloc.c:66: error: invalid application of `sizeof' to an incomplete type
dl-reloc.c: In function `_dl_nothread_init_static_tls':
dl-reloc.c:109: error: syntax error before "__self"
dl-reloc.c:109: error: `__self' undeclared (first use in this function)
dl-reloc.c:109: error: (Each undeclared identifier is reported only once
dl-reloc.c:109: error: for each function it appears in.)

I was pleased to note that dl-runtime compiled with this version, but cannot
live with the TLS breakage.  (Since I made zero changes in my system between
these two build attempts, I am now 100% convinced the dl-runtime problem is not
in my build environment).

What version of the kernel headers are you using on your build machine?  Are
they Red Hat modified headers, or stock from kernel.org?  We're using 2.4.27 at
the moment, since that is what is current from kernel.org.  The README file says
that 2.x is supported on Linux for S/390, so I'm hoping that isn't an issue.

I know you can't retroactively fix CVS snapshots.  I'm just trying to find the
minimum patch necessary to get this thing to build so we can ship it.  To be
100% honest, if you tell me that inserting the #include is an acceptable
workaround, I'll take that as sufficient and run with it.  I just cannot make
that assessment by myself.
Comment 7 Mark Post 2004-09-26 23:15:44 UTC
I've now got a hint as to why the difference between the two versions.  On the
CVS from 08/04, HAVE_TLS_SUPPORT is not being defined.  On the CVS from 09/26,
it is.  This means that the "#  include <sysdep.h>" is not being pulled in,
causing the failure.  Now I just need to see why isn't being defined for the
08/04 CVS.

In case anyone is wondering, I'm doing this so that they next poor slob that
comes along (if any do) won't have to deal with this issue.
Comment 8 Mark Post 2004-09-27 00:13:58 UTC
And, the answer to that question is right here:
2004-08-27  Roland McGrath  <roland@redhat.com>
        * configure.in (usetls): Default to yes.

I'm not in the process of re-compiling the 08/04 CVS with an explicit --with-tls
in the ./configure statement.
Comment 9 Mark Post 2004-09-27 00:27:04 UTC
And, that brings us back to the previous problem of getting this error:
dl-reloc.c: In function `_dl_allocate_static_tls':
dl-reloc.c:66: error: invalid application of `sizeof' to an incomplete type
dl-reloc.c: In function `_dl_nothread_init_static_tls':
dl-reloc.c:109: error: syntax error before "__self"
dl-reloc.c:109: error: `__self' undeclared (first use in this function)
dl-reloc.c:109: error: (Each undeclared identifier is reported only once
dl-reloc.c:109: error: for each function it appears in.)

Looks like I'll be spending more time on debugging this.
Comment 10 GOTO Masanori 2004-09-27 11:37:03 UTC
Note that I understand why my past built on S390
was failed:

http://sources.redhat.com/ml/libc-alpha/2004-07/msg00023.html

I think S390 cannot be built with --without-tls, without my patch.  In addition,
this patch is sane,
because CFI directive is defined in sysdep.h.
Comment 11 Mark Post 2004-09-27 17:14:08 UTC
I agree.  Using --without-tls on a 2.4.x system requires an additional #include
<sysdep.h> somewhere, or have it moved outside the #ifdef HAVE_TLS_SUPPORT
clause in linuxthreads/sysdeps/s390/tls.h.

Trying to build glibc --with-tls on a 2.4.x system appears to be very broken, to
say the least.
Comment 12 Mark Post 2004-09-27 22:24:22 UTC
I think I like this patch better.  It has a couple of advantages.  It only hits
one file instead of two, but still catches both 31 and 64 bit platforms.  Both
Debian and Slack/390 already have a patch against that file.  If there is some
reason why it is only included when __ASSEMBLER__ is not defined, then this
preserves that.
--- tls.h.orig  2003-01-30 13:34:11.000000000 -0500
+++ tls.h       2004-09-27 18:19:18.000000000 -0400
@@ -122,6 +122,8 @@
 #else  /* HAVE_TLS_SUPPORT && (FLOATING_STACKS || !IS_IN_libpthread) */

 # ifndef __ASSEMBLER__
+/* Get system call information.  */
+#  include <sysdep.h>

 /* Get the thread descriptor definition.  */
 #  include <linuxthreads/descr.h>


What do you think?
Comment 13 Mark Post 2004-09-27 22:25:17 UTC
Hmph.  I should have done a better job with the diff headers.  This is against
linuxthreads/sysdeps/s390/tls.h
Comment 14 Jim Tison 2005-01-09 21:42:07 UTC
(In reply to comment #13)
> Hmph.  I should have done a better job with the diff headers.  This is against
> linuxthreads/sysdeps/s390/tls.h
> 

So just for formality's sake (don't ask me why ... it's a REALLY long story, but
this patch is needed elsewhere), I am reposting your patch with the proper
headers on it. Thanks for the patch in the first place, Mark. 

--- linuxthreads/sysdeps/s390/tls.h.orig  2003-01-30 13:34:11.000000000 -0500
+++ linuxthreads/sysdeps/s390/tls.h       2004-09-27 18:19:18.000000000 -0400
@@ -122,6 +122,8 @@
 #else  /* HAVE_TLS_SUPPORT && (FLOATING_STACKS || !IS_IN_libpthread) */

 # ifndef __ASSEMBLER__
+/* Get system call information.  */
+#  include <sysdep.h>

 /* Get the thread descriptor definition

Comment 15 Ulrich Drepper 2005-09-23 20:03:25 UTC
Support for LinuxThreads is gone.
Comment 16 Mike Frysinger 2006-02-23 04:25:52 UTC
> http://sources.redhat.com/ml/libc-alpha/2004-07/msg00023.html

so this is still broken on the glibc-2.3 branch ... i guess the verdict here is
that it'll never be fixed in 2.3 ?  i know this doesnt carry much wait with the
glibc maintainers, but we've hit this bug in the Gentoo/s390 port ...

glibc head does not suffer from this problem as the dl-machine.h files have been
reworked since and the relevant code no longer exists ...
Comment 17 cvs-commit@gcc.gnu.org 2006-02-23 22:36:55 UTC
Subject: Bug 398

CVSROOT:	/cvs/glibc
Module name:	libc
Branch: 	glibc-2_3-branch
Changes by:	roland@sources.redhat.com	2006-02-23 22:36:51

Modified files:
	sysdeps/s390/s390-64: dl-machine.h 
	sysdeps/s390/s390-32: dl-machine.h 

Log message:
	2004-07-10  GOTO Masanori  <gotom@debian.or.jp>
	
	[BZ #398]
	* sysdeps/s390/s390-32/dl-machine.h: Include <sysdep.h> for CFI
	directive.
	* sysdeps/s390/s390-64/dl-machine.h: Likewise.

Patches:
http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/sysdeps/s390/s390-64/dl-machine.h.diff?cvsroot=glibc&only_with_tag=glibc-2_3-branch&r1=1.19.4.1&r2=1.19.4.2
http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/sysdeps/s390/s390-32/dl-machine.h.diff?cvsroot=glibc&only_with_tag=glibc-2_3-branch&r1=1.20.4.1&r2=1.20.4.2

Comment 18 Jackie Rosen 2014-02-16 19:30:28 UTC Comment hidden (spam)