From owner-freebsd-toolchain@FreeBSD.ORG Wed Jun 11 12:41:31 2014 Return-Path: Delivered-To: freebsd-toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9DE71A3; Wed, 11 Jun 2014 12:41:31 +0000 (UTC) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cloud.theravensnest.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D9E322F2; Wed, 11 Jun 2014 12:41:27 +0000 (UTC) Received: from [192.168.0.96] (cpc14-cmbg15-2-0-cust307.5-4.cable.virginm.net [82.26.1.52]) (authenticated bits=0) by theravensnest.org (8.14.7/8.14.7) with ESMTP id s5BCfMRh064603 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 11 Jun 2014 12:41:24 GMT (envelope-from theraven@FreeBSD.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: abi::__cxa_demangle provides invalid result on non-mangled symbols From: David Chisnall In-Reply-To: <20140611123054.GA2777@soulhacker> Date: Wed, 11 Jun 2014 13:41:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <281D8767-7B24-4B58-8669-CF60C597E58E@FreeBSD.org> References: <9BDAE8E2-0573-4526-9136-97D3492D7DEF@FreeBSD.org> <20140611123054.GA2777@soulhacker> To: Kai Wang X-Mailer: Apple Mail (2.1874) Cc: Ryan Stone , freebsd-toolchain@FreeBSD.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 12:41:31 -0000 On 11 Jun 2014, at 13:30, Kai Wang wrote: > On Tue, Jun 10, 2014 at 07:38:19AM +0100, David Chisnall wrote: >> On 10 Jun 2014, at 03:44, Ed Maste wrote: >>=20 >>> I had the same issue in LLVM, and as hacky as it seems, the solution >>> is to check that the name starts with "_Z" before passing it to >>> __cxa_demangle. >>>=20 >>> For reference the LLVM review for the change is here: >>> http://reviews.llvm.org/D2552 >>>=20 >>> I didn't get around to testing it on Linux; since you have a test >>> application ready it would be interesting to see the result of >>> __cxa_demangle("f") there. >>=20 >> If you know that the thing that you are demangling is a symbol name, = then you can use the _Z check, which isn't really a hack - it's a marker = added to identify C++ symbols. Note that, if you're writing portable = code, you need to remember that some systems prepend an underscore to = all compiler-generated symbols, so you may also need to check for __Z = and trim the leading _. >>=20 >> The __cxa_demangle() function has to handle things that are not just = symbols (types and so on) and so can't do this test itself. Its most = common use is generating a human-friendly error for an uncaught = exception, where it is just parsing a type encoding. >>=20 >> The demangler that we ship is from libelftc. It also fails on a = number of C++11 types and doesn't handle some complex template cases. =20= >=20 > Hi David, >=20 > If possible, could you list a few examples that the demangler can not > handle? Maybe we can fix this in libelftc and merge it back later. Your best reference for this is the libc++abi test suite: = http://llvm.org/viewvc/llvm-project/libcxxabi/trunk/test/test_demangle.cpp= ?revision=3D208611&view=3Dmarkup New C++11 additions and template arguments that are forward references = are not very well handled. It would be great if there were any = improvements. It would also be good for libcxxrt if the demangler could avoid having = to allocate any memory except on the stack, as one of the places where = it's used is in reporting out-of-memory conditions. David