Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 1 Apr 2013 20:04:45 +0200
From:      Dimitry Andric <dim@FreeBSD.org>
To:        Andriy Gapon <avg@freebsd.org>
Cc:        svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org
Subject:   Re: svn commit: r247962 - head/cddl/contrib/opensolaris/tools/ctf/cvt
Message-ID:  <784ED932-664A-4880-8BCA-A7872E947920@FreeBSD.org>
In-Reply-To: <51592416.7090003@FreeBSD.org>
References:  <201303072243.r27Mhopv039449@svn.freebsd.org> <51592416.7090003@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help

--Apple-Mail=_A2CE05B9-CEAE-42DE-8F54-EF1E9DBC05C5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Apr 1, 2013, at 08:07, Andriy Gapon <avg@freebsd.org> wrote:
> on 08/03/2013 00:43 Dimitry Andric said the following:
>> Author: dim
>> Date: Thu Mar  7 22:43:50 2013
>> New Revision: 247962
>> URL: http://svnweb.freebsd.org/changeset/base/247962
>>=20
>> Log:
>>  Fix error in r247960: actually assign the basename to =
match.iim_file.
>=20
> I've got some bad news.
>=20
> First of all, sorry for not being thorough enough when this change was
> originally proposed.  I rebuilt only ctfconvert with the patch, but =
ctfmerge was
> left alone.
>=20
> It seems that r247960 + r247962 (this commit) broke ctfmerge in my =
environment
> (head + clang).  While .o files have expected ctf information, =
combined files
> miss ctf data for functions.
Do you have a good test case?  I tried building a few kernel modules,
but I do see ctf data for functions, at least in ctfdump output.

Also, a simple test case with a pair of .o files, each containing a
function, seems to work properly when processed with ctfmerge.

> I haven't dug yet into this problem, but I suspect that there is some =
mismatch
> at another place (or even multiple places) where STT_FILE is used.

The only other place is cddl/contrib/opensolaris/tools/ctf/cvt/input.c,
so I more or less blindly made the attached diff, which might solve the
problem.  Can you please try it in your environment?


--Apple-Mail=_A2CE05B9-CEAE-42DE-8F54-EF1E9DBC05C5
Content-Disposition: attachment;
	filename=ctf-input-stt_file-1.diff
Content-Type: application/octet-stream;
	name="ctf-input-stt_file-1.diff"
Content-Transfer-Encoding: 7bit

Index: cddl/contrib/opensolaris/tools/ctf/cvt/input.c
===================================================================
--- cddl/contrib/opensolaris/tools/ctf/cvt/input.c	(revision 248699)
+++ cddl/contrib/opensolaris/tools/ctf/cvt/input.c	(working copy)
@@ -387,6 +387,7 @@ GElf_Sym *
 symit_next(symit_data_t *si, int type)
 {
 	GElf_Sym sym;
+	char *bname;
 	int check_sym = (type == STT_OBJECT || type == STT_FUNC);
 
 	for (; si->si_next < si->si_nument; si->si_next++) {
@@ -394,8 +395,10 @@ symit_next(symit_data_t *si, int type)
 		gelf_getsym(si->si_symd, si->si_next, &sym);
 		si->si_curname = (caddr_t)si->si_strd->d_buf + sym.st_name;
 
-		if (GELF_ST_TYPE(sym.st_info) == STT_FILE)
-			si->si_curfile = si->si_curname;
+		if (GELF_ST_TYPE(sym.st_info) == STT_FILE) {
+			bname = strrchr(si->si_curname, '/');
+			si->si_curfile = bname == NULL ? si->si_curname : bname + 1;
+		}
 
 		if (GELF_ST_TYPE(sym.st_info) != type ||
 		    sym.st_shndx == SHN_UNDEF)

--Apple-Mail=_A2CE05B9-CEAE-42DE-8F54-EF1E9DBC05C5--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?784ED932-664A-4880-8BCA-A7872E947920>