From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 4 11:50:06 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2F2A4D51; Mon, 4 Mar 2013 11:50:06 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) by mx1.freebsd.org (Postfix) with ESMTP id E4BA8125A; Mon, 4 Mar 2013 11:50:05 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:204:4bff:fe01:de8a] (spaceball.andric.com [IPv6:2001:7b8:3a7:0:204:4bff:fe01:de8a]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 929855C43; Mon, 4 Mar 2013 12:50:04 +0100 (CET) Message-ID: <51348A6A.3070606@FreeBSD.org> Date: Mon, 04 Mar 2013 12:50:02 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20130117 Thunderbird/19.0 MIME-Version: 1.0 To: Andriy Gapon Subject: Re: clang generated code sometimes confuses fbt References: <5132387E.8010808@FreeBSD.org> <51323C62.4040506@FreeBSD.org> <51325FB3.7080300@FreeBSD.org> <51337018.30000@FreeBSD.org> <51337C27.7000105@FreeBSD.org> <5133AC3B.5040504@FreeBSD.org> In-Reply-To: <5133AC3B.5040504@FreeBSD.org> Content-Type: multipart/mixed; boundary="------------060403060209040404050200" Cc: freebsd-hackers@FreeBSD.org 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: Mon, 04 Mar 2013 11:50:06 -0000 This is a multi-part message in MIME format. --------------060403060209040404050200 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 2013-03-03 21:02, Dimitry Andric wrote: > On 2013-03-03 17:36, Andriy Gapon wrote: >> on 03/03/2013 17:45 Dimitry Andric said the following: ... > So to fix this inconsistency, we could either change dw_read() to use > the full name instead of the basename, or change sort_iidescs() to use > the basename instead of the full name. > > The only upstream I have been able to find, Illumos, had the same code > as FreeBSD for both of these functions, so it is likely they never > noticed it before... > > My preference would be to remove the basename() call from dw_read(), as > in the attached diff. That seems to fix the problem here; the diff of > ctfdump output before and after becomes: Actually, that way of fixing breaks it for gcc, so it should really be fixed in sort_iidescs() instead. See attached diff; I verified it works for both gcc-compiled and clang-compiled objects. --------------060403060209040404050200 Content-Type: text/x-diff; name="ctfconvert-output-1.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ctfconvert-output-1.diff" Index: cddl/contrib/opensolaris/tools/ctf/cvt/output.c =================================================================== --- cddl/contrib/opensolaris/tools/ctf/cvt/output.c (revision 247448) +++ cddl/contrib/opensolaris/tools/ctf/cvt/output.c (working copy) @@ -363,6 +363,7 @@ sort_iidescs(Elf *elf, const char *file, tdata_t * for (i = 0; i < nent; i++) { GElf_Sym sym; + char *bname; iidesc_t **tolist; GElf_Sym ssym; iidesc_match_t smatch; @@ -377,6 +378,8 @@ sort_iidescs(Elf *elf, const char *file, tdata_t * switch (GELF_ST_TYPE(sym.st_info)) { case STT_FILE: + bname = strrchr(match.iim_name, '/'); + bname = bname == NULL ? match.iim_name : bname + 1; match.iim_file = match.iim_name; continue; case STT_OBJECT: --------------060403060209040404050200--