Date: Sat, 2 Mar 2013 22:52:23 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Dimitry Andric <dim@FreeBSD.org> Cc: freebsd-hackers@FreeBSD.org, Andriy Gapon <avg@FreeBSD.org> Subject: Re: clang generated code sometimes confuses fbt Message-ID: <20130302205223.GR2930@kib.kiev.ua> In-Reply-To: <51325FB3.7080300@FreeBSD.org> References: <5132387E.8010808@FreeBSD.org> <51323C62.4040506@FreeBSD.org> <51325FB3.7080300@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 "<stdin>";
>=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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130302205223.GR2930>