From owner-svn-src-head@FreeBSD.ORG Thu Sep 6 19:58:44 2012 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 29B9D1065677; Thu, 6 Sep 2012 19:58:44 +0000 (UTC) (envelope-from rpaulo@FreeBSD.org) Received: from felyko.com (stark.strangled.net [IPv6:2607:f2f8:a528::3:1337:ca7]) by mx1.freebsd.org (Postfix) with ESMTP id BB9C28FC0A; Thu, 6 Sep 2012 19:58:43 +0000 (UTC) Received: from [IPv6:2601:9:4d00:85:6c92:3a9f:f4ca:fb77] (unknown [IPv6:2601:9:4d00:85:6c92:3a9f:f4ca:fb77]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by felyko.com (Postfix) with ESMTPSA id 44FDC3981E; Thu, 6 Sep 2012 12:58:43 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Rui Paulo In-Reply-To: <20120906094238.GF85904@gpr.nnz-home.ru> Date: Thu, 6 Sep 2012 12:58:42 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <00E6EB72-A6D5-4611-819F-ACEF6135BAFF@FreeBSD.org> References: <201209060319.q863JnDe050504@svn.freebsd.org> <20120906094238.GF85904@gpr.nnz-home.ru> To: Gennady Proskurin X-Mailer: Apple Mail (2.1486) Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r240156 - head/lib/libproc X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 19:58:44 -0000 On 6 Sep 2012, at 02:42, Gennady Proskurin wrote: > On Thu, Sep 06, 2012 at 03:19:49AM +0000, Rui Paulo wrote: >> Author: rpaulo >> Date: Thu Sep 6 03:19:48 2012 >> New Revision: 240156 >> URL: http://svn.freebsd.org/changeset/base/240156 >>=20 >> Log: >> Add support for demangling C++ symbols. This requires linking = libproc with >> libc++rt/libsupc++. >>=20 >> Discussed with: theraven >>=20 >> Modified: >> head/lib/libproc/Makefile >> head/lib/libproc/proc_sym.c >>=20 >> Modified: head/lib/libproc/Makefile >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >> --- head/lib/libproc/Makefile Thu Sep 6 02:07:58 2012 = (r240155) >> +++ head/lib/libproc/Makefile Thu Sep 6 03:19:48 2012 = (r240156) >> @@ -1,5 +1,7 @@ >> # $FreeBSD$ >>=20 >> +.include >> + >> LIB=3D proc >>=20 >> SRCS=3D proc_bkpt.c \ >> @@ -13,6 +15,14 @@ INCS=3D libproc.h >>=20 >> CFLAGS+=3D -I${.CURDIR} >>=20 >> +.if ${MK_LIBCPLUSPLUS} !=3D "no" >> +LDADD+=3D -lcxxrt >> +DPADD+=3D ${LIBCXXRT} >> +.else >> +LDADD+=3D -lsupc++ >> +DPADD+=3D ${LIBSTDCPLUSPLUS} >> +.endif >> + >> SHLIB_MAJOR=3D 2 >>=20 >> WITHOUT_MAN=3D >>=20 >> Modified: head/lib/libproc/proc_sym.c >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >> --- head/lib/libproc/proc_sym.c Thu Sep 6 02:07:58 2012 = (r240155) >> +++ head/lib/libproc/proc_sym.c Thu Sep 6 03:19:48 2012 = (r240156) >> @@ -46,6 +46,8 @@ >>=20 >> #include "_libproc.h" >>=20 >> +extern char *__cxa_demangle(const char *, char *, size_t *, int *); >> + >> static void proc_rdl2prmap(rd_loadobj_t *, prmap_t *); >>=20 >> static void >> @@ -266,7 +268,11 @@ proc_addr2sym(struct proc_handle *p, uin >> if (addr >=3D rsym && addr <=3D (rsym + sym.st_size)) { >> s =3D elf_strptr(e, dynsymstridx, sym.st_name); >> if (s) { >> - strlcpy(name, s, namesz); >> + if (strlen(s) > 2 &&=20 >> + s[0] =3D=3D '_' && s[1] =3D=3D 'Z') > checking "strlen(s) > 2" is useless and not optimal here, you can omit = it completely > checking s[0] and s[1] is enough, it implies that length is >=3D2 > you may add something like "s[2] !=3D 0" if length should be strictly = >2 It's not really useless but can be considered non-optimal, yes. That = said, the C++ demangler we're calling doesn't really care about being = fast :-)=20 Regards, -- Rui Paulo