From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 2 20:52:33 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5896443C; Sat, 2 Mar 2013 20:52:33 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id A62E61E5; Sat, 2 Mar 2013 20:52:32 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r22KqNMT031061; Sat, 2 Mar 2013 22:52:23 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.0 kib.kiev.ua r22KqNMT031061 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r22KqNqm031060; Sat, 2 Mar 2013 22:52:23 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 2 Mar 2013 22:52:23 +0200 From: Konstantin Belousov To: Dimitry Andric Subject: Re: clang generated code sometimes confuses fbt Message-ID: <20130302205223.GR2930@kib.kiev.ua> References: <5132387E.8010808@FreeBSD.org> <51323C62.4040506@FreeBSD.org> <51325FB3.7080300@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VdnGiXwuH6t1Tqzo" Content-Disposition: inline In-Reply-To: <51325FB3.7080300@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-hackers@FreeBSD.org, Andriy Gapon X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 20:52:33 -0000 --VdnGiXwuH6t1Tqzo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Mar 02, 2013 at 09:23:15PM +0100, Dimitry Andric wrote: > On 2013-03-02 18:52, Andriy Gapon wrote: > > on 02/03/2013 19:35 Andriy Gapon said the following: > >> Now, I am not quite sure why ctfconvert skips bpobj_iterate_impl in the > >> clang-generated code. Seems like some sort of a bug in ctfconvert. > > > > It seems that gcc and clang put different names for symbol of type FILE: > > clang: > > readelf -a -W /usr/obj/usr/src/sys/TRANT/bpobj.o| fgrep -w FILE > > 1: 0000000000000000 0 FILE LOCAL DEFAULT ABS > > /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/bpobj.c > > > > gcc: > > readelf -a -W /usr/obj/usr/src/sys/ODYSSEY/bpobj.o| fgrep -w FILE > > 1: 0000000000000000 0 FILE LOCAL DEFAULT ABS bpobj.c > > > > ctfconvert seems to compare this value with "bpobj.c" and so in the cla= ng case > > it doesn't recognize the static symbols. > > > > Does my analysis seem reasonable? >=20 > Have you verified that ctfconvert does the right thing, if you modify > the FILE symbol to have just the filename? >=20 > Indeed, clang puts the original filename from the command line in the > .file directive, while gcc explicitly removes any directory names; see > contrib/gcc/toplev.c, around line 680: >=20 > void > output_file_directive (FILE *asm_file, const char *input_name) > { > int len; > const char *na; >=20 > if (input_name =3D=3D NULL) > input_name =3D ""; >=20 > len =3D strlen (input_name); > na =3D input_name + len; >=20 > /* NA gets INPUT_NAME sans directory names. */ > while (na > input_name) > { > if (IS_DIR_SEPARATOR (na[-1])) > break; > na--; > } > ... >=20 > That "NA gets INPUT_NAME sans directory names" comment was inserted by > rms in r279. :-) So I guess this is the way gcc has done it from the > start, but there is no explanation as to why rms chose to remove those > directory names. I do not see the problem, except maybe for having > reproducible builds? I seems that at least gdb also depends on the stripping the path for stabs (which is not dwarf) debugging format interpretation. On the FreeBSD system, do 'info', select 'stabs' -> Stab Sections -> Elf Linker Relocation. The last paragraph documents the gdb requirements. So it seems that stripped path in the STT_FILE is the common expectation. --VdnGiXwuH6t1Tqzo Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRMmaHAAoJEJDCuSvBvK1BY2sQAJrnIETDlx7M+Z80EA3swFot wCJ3vd8Y4+HfECXSGxCbPxE7OOAhmnlns5Ub5HSt3qzq+KDJ9O455E4AscOA0V/N 0OMiLW5+7abGbtPXtf6zr6at3rou/rq1NGg3gln7S+qJcb0HzhOFy8MnivY59miv 1CRVIAXgiXemmzgamDnCAsoJyG1jp1DyEvKcDkF833n9mlZqdRe2gIJZfJL/ldjB BCsipwIkOsgAZd+f3VZDMGK50cgeHNMeSFzzareDr0aqI7chIlAxnX9dQxoasnPt 5z+GD/MlLc0CJ2mHXywi2Tq1vYt6D6fjgyd22paRgvN9fRvpJYK3fMI/t8KgD0B2 I0KcRZ9dmm04ULSXbbnQFSdUyOofmRtow9a+Bwd/EnAqiz+ec03mvb72EVanP6Jo nkyOf5AS5M+WMDfIbX23JyGRuxFvaMMng/kwk65vJEEJ6vh8CfQkTkerWJCNZEOx ZjET8aWuoAlC7xmgM/S1RCicHNFuPHcFt8lEIwXE5YjtPZycUMXPXTLWgwPNTCip +sc7YcBDQ1DW8Gr0CvcKgeBDBaxUD8rWSCON+4SFVi2hggInXZCxpfsGDNGqdvs6 bP3ZyzehGFnWjUc0szNVDQQtqBLWstdV73y+yj61Yg2sEMdEjtTWtJE61R7+atke pRNNNSd+2F7h1oD79Q4z =3KDl -----END PGP SIGNATURE----- --VdnGiXwuH6t1Tqzo--