On Mar 2, 2014, at 6:16 AM, Dimitry Andric <[email protected]> wrote: > On 21 Feb 2014, at 23:47, Justin T. Gibbs <[email protected]> wrote: >> On Feb 20, 2014, at 10:26 AM, Roman Divacky <[email protected]> wrote: >> >>> The dwarf backend for ctfconvert was completely reimplemented a few weeks >>> ago. >>> It's now based on elftoolchain libdwarf. >>> >>> Test on current. >> >> The failures I’ve 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). > > I've just tried your patch, building devd, and it seemed to have worked > just fine (though I had to use DEBUG_FLAGS=-g, otherwise ctfconvert > would complain there was no type data to convert):
My buildworld currently dies with the ATF library:
--- lib/atf__L ---
--- fs.So ---
ctfconvert -L VERSION -g fs.So
--- process.So ---
ctfconvert -L VERSION -g process.So
--- lib/libutil__L ---
ctfconvert -L VERSION -g property.o
--- lib/atf__L ---
--- fs.So ---
Segmentation fault
*** [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:
>
> ((${BOOTSTRAPPING} < 800038 && !(${BOOTSTRAPPING} >= 700112 &&
> ${BOOTSTRAPPING} < 799999))
>
> to:
>
> ((${BOOTSTRAPPING} < 1000034 && !(${BOOTSTRAPPING} >= 901505 &&
> ${BOOTSTRAPPING} < 999999))
>
> but maybe the 9.x range check is now too narrow?
Why don’t 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?
—
Justin
signature.asc
Description: Message signed with OpenPGP using GPGMail
