From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17011 invoked by alias); 8 Sep 2004 19:44:36 -0000 Mailing-List: contact libc-hacker-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-hacker-owner@sources.redhat.com Received: (qmail 16995 invoked from network); 8 Sep 2004 19:44:36 -0000 Received: from unknown (HELO Cantor.suse.de) (195.135.220.2) by sourceware.org with SMTP; 8 Sep 2004 19:44:36 -0000 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id 9A917BAF5C0; Wed, 8 Sep 2004 21:44:35 +0200 (CEST) Received: from aj by arthur.inka.de with local (Exim 4.30) id 1C58Mr-0005cu-LN; Wed, 08 Sep 2004 21:44:33 +0200 From: Andreas Jaeger Organization: SUSE Linux AG To: libc-hacker@sources.redhat.com Subject: Re: Fix locale/weight.h with GCC 3.5 Date: Wed, 08 Sep 2004 19:44:00 -0000 User-Agent: KMail/1.7 Cc: Roland McGrath References: <200409081701.i88H1lmf031187@magilla.sf.frob.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3063279.BGvtmpCy1u"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200409082144.33512.aj@suse.de> X-SW-Source: 2004-09/txt/msg00034.txt.bz2 --nextPart3063279.BGvtmpCy1u Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-length: 2196 On Wednesday 08 September 2004 19:24, Andreas Jaeger wrote: > Roland McGrath writes: > >> -static inline void > >> +inline void > >> +__attribute ((always_inline)) > >> elf_machine_rela (struct link_map *map, const Elf64_Rela *reloc, > >> const Elf64_Sym *sym, const struct r_found_version *version, > >> void *const reloc_addr_arg) > > > > Does this really do the right thing in all of 3.[345]? > > I would think this would generate an external entry point too. > > It seems so :-( > > $ nm dl-conflict.os > U _dl_argv_internal > U _dl_dprintf > U _dl_reloc_bad_type > 00000000000000a0 T _dl_resolve_conflicts > 0000000000000000 t elf_machine_rela.0 > U _GLOBAL_OFFSET_TABLE_ > 0000000000000017 r .LC0 > 0000000000000000 r .LC1 > 0000000000000000 r .LC2 > U _rtld_local > U _rtld_local_ro > > So, should I add #ifndef RESOLVE here also? Wait - this seems to be produced even with the current glibc without my=20 changes (glibc compiled by GCC 3.3): nm /lib64/ld-linux-x86-64.so.2 |grep elf_machine_rela 0000000000000d40 t elf_machine_rela.0 0000000000007fa0 t elf_machine_rela.0 000000000000d010 t elf_machine_rela.0 0000000000000d70 t elf_machine_rela_relative.1 0000000000008330 t elf_machine_rela_relative.1 For reference, compile: int test (int j) { =20=20 static inline int __attribute__ ((always_inline)) test_inline (int i) { return i++; } =20=20 return test_inline (j); } I get with GCC 3.3: gromit:/tmp:[0]$ gcc -Wall -c t.c -O2 gromit:/tmp:[0]$ nm t.o 0000000000000010 T test 0000000000000000 t test_inline.0 But with 3.4 (and also 3.5 removing the static): gromit:/tmp:[0]$ /opt/gcc/3.4-devel/bin/gcc -Wall -c t.c -O2 gromit:/tmp:[0]$ nm t.o 0000000000000000 T test It's a local entry point in 3.3. The local entry point exists for me with both 3.3 and 3.5 in dl-reloc.o. I guess we should go with my patch. Ok?=20 Andreas --=20 Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj SUSE Linux AG, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GPG fingerprint =3D 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 --nextPart3063279.BGvtmpCy1u Content-Type: application/pgp-signature Content-length: 189 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBBP2EhOJpWPMJyoSYRAhgCAKCMHGX2jnBnNA0yG77hUrfUn3S8oACfTGhg CApVAmGjYjAOrjXfBGZWDpw= =eQVE -----END PGP SIGNATURE----- --nextPart3063279.BGvtmpCy1u--