ctfconvert broken for C++ objects?

[Justin T. Gibbs]

On Mar 2, 2014, at 6:16 AM, Dimitry Andric <dim at FreeBSD.org> wrote:

> On 21 Feb 2014, at 23:47, Justin T. Gibbs <gibbs at FreeBSD.org> wrote:
>> On Feb 20, 2014, at 10:26 AM, Roman Divacky <rdivacky at freebsd.org> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-toolchain/attachments/20140302/804e7d83/attachment.sig>