Date: Sun, 2 Mar 2014 10:55:20 -0700 From: "Justin T. Gibbs" <gibbs@freebsd.org> To: Dimitry Andric <dim@FreeBSD.org> Cc: freebsd-toolchain@freebsd.org Subject: Re: ctfconvert broken for C++ objects? Message-ID: <A0808310-3CF4-4FE1-B9FD-53DD8F9F9ADC@freebsd.org> In-Reply-To: <FFB0AF4E-BC44-49E5-8272-930668363A52@FreeBSD.org> References: <216B816A-8ADA-438F-B834-8C386C5BC460@FreeBSD.org> <20140220172608.GA85526@freebsd.org> <81C07491-7E51-4CF0-B257-88ED998EE2A0@FreeBSD.org> <FFB0AF4E-BC44-49E5-8272-930668363A52@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_FAF32865-6971-46E2-AD7F-D314F4E35FDC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=windows-1252
On Mar 2, 2014, at 6:16 AM, Dimitry Andric <dim@FreeBSD.org> wrote:
> On 21 Feb 2014, at 23:47, Justin T. Gibbs <gibbs@FreeBSD.org> wrote:
>> On Feb 20, 2014, at 10:26 AM, Roman Divacky <rdivacky@freebsd.org> =
wrote:
>>=20
>>> The dwarf backend for ctfconvert was completely reimplemented a few =
weeks ago.
>>> It's now based on elftoolchain libdwarf.
>>>=20
>>> Test on current.
>>=20
>> The failures I=92ve experienced occur when attempting to ctfconvert =
the C++ code in the base (e.g. ATF or devd). You can replicate the =
failures on head by applying the share/mk patch below (a version of my =
previous patch rebased on head).
>=20
> I've just tried your patch, building devd, and it seemed to have =
worked
> just fine (though I had to use DEBUG_FLAGS=3D-g, otherwise ctfconvert
> would complain there was no type data to convert):
My buildworld currently dies with the ATF library:
--- lib/atf__L --- =
=20
--- fs.So --- =
=20
ctfconvert -L VERSION -g fs.So =
=20
--- process.So --- =
=20
ctfconvert -L VERSION -g process.So =
=20
--- lib/libutil__L --- =
=20
ctfconvert -L VERSION -g property.o =
=20
--- lib/atf__L --- =
=20
--- fs.So --- =
=20
Segmentation fault =
=20
*** [fs.So] Error code 139
Can you build all of world with my patch?
> This was last changed by Brooks in r251689: "Be more agressive about
> bootstrapping ctfmerge and ctfconvert so builds from existing releases
> have a chance of working properly". The range check was modified =
from:
>=20
> ((${BOOTSTRAPPING} < 800038 && !(${BOOTSTRAPPING} >=3D 700112 && =
${BOOTSTRAPPING} < 799999))
>=20
> to:
>=20
> ((${BOOTSTRAPPING} < 1000034 && !(${BOOTSTRAPPING} >=3D 901505 && =
${BOOTSTRAPPING} < 999999))
>=20
> but maybe the 9.x range check is now too narrow?
Why don=92t we always bootstrap the ctf toolchain when WITH_CTF is =
defined? How else would a user migrate from an old tree to a new which =
enables newly supported features of ctf (e.g. its use on C++ programs) =
that require the new tools?
=97
Justin
--Apple-Mail=_FAF32865-6971-46E2-AD7F-D314F4E35FDC
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iQEcBAEBAgAGBQJTE3CIAAoJED9n8CuvaSf4Xk8H/jk5m2fEkmmbFghQ3Sk/xDat
FtQ9tosQ1siFLvxyJEBnJQ892vKsmi+pcUtPDlRY50G+I9n2k2kOjqwh9dtpNoT1
Ygfu5KR/uViHetLqLZREfh3wGIR9n+m9uKmH/GbmQ7XmaOJwm+xlp24Yd4brgY38
/ioLknu+qjFdgQPPVrWZlWrF+3/yPepKaVVqWGMhLGsggx+qDStgeQHIPhTg6zh9
wjfZd3k4K2FjbRAbF1sw3kIN1n0dQ86fl2cg4JEeWCxqKOF5qlgC2XRepyxV+89+
4p9I/11XvgNG8EDlVc6cBKjpQ47df6HyKH4gdcjWP/EgHu9qPywDLTO8eAlHeDg=
=tBY0
-----END PGP SIGNATURE-----
--Apple-Mail=_FAF32865-6971-46E2-AD7F-D314F4E35FDC--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A0808310-3CF4-4FE1-B9FD-53DD8F9F9ADC>