Re: ctfconvert broken for C++ objects?
On Mar 2, 2014, at 6:16 AM, Dimitry Andric wrote:
> On 21 Feb 2014, at 23:47, Justin T. Gibbs wrote:
>> On Feb 20, 2014, at 10:26 AM, Roman Divacky 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} < 79))
>
> to:
>
> ((${BOOTSTRAPPING} < 134 && !(${BOOTSTRAPPING} >= 901505 &&
> ${BOOTSTRAPPING} < 99))
>
> 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
Re: ctfconvert broken for C++ objects?
On 21 Feb 2014, at 23:47, Justin T. Gibbs wrote:
> On Feb 20, 2014, at 10:26 AM, Roman Divacky 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):
$ make WITH_CTF=x DEBUG_FLAGS=-g
c++ -O2 -pipe -I. -I/usr/src/sbin/devd -g -Qunused-arguments -fstack-protector
-Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter
-Wpointer-arith -Wno-uninitialized -Wno-empty-body -Wno-string-plus-int
-Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value
-Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -g
-Wno-c++11-extensions -c /usr/src/sbin/devd/devd.cc
cc -O2 -pipe -I. -I/usr/src/sbin/devd -g -std=gnu99 -Qunused-arguments
-fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W
-Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
-Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int
-Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value
-Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -c token.c
ctfconvert -L VERSION -g token.o
cc -O2 -pipe -I. -I/usr/src/sbin/devd -g -std=gnu99 -Qunused-arguments
-fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W
-Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
-Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int
-Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value
-Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -c parse.c
ctfconvert -L VERSION -g parse.o
c++ -O2 -pipe -I. -I/usr/src/sbin/devd -g -Qunused-arguments -fstack-protector
-Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter
-Wpointer-arith -Wno-uninitialized -Wno-empty-body -Wno-string-plus-int
-Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value
-Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -g
-Wno-c++11-extensions -static -o devd devd.o token.o parse.o -ll -lutil
ctfmerge -L VERSION -g -o devd devd.o token.o parse.o
gzip -cn /usr/src/sbin/devd/devd.8 > devd.8.gz
gzip -cn /usr/src/sbin/devd/devd.conf.5 > devd.conf.5.gz
$ ctfdump -S /usr/obj/usr/src/sbin/devd/devd
- CTF Statistics -
total number of data objects= 627
total number of functions = 31
total number of function arguments = 25
maximum argument list length= 2
average argument list length= 0.81
total number of types = 97
total number of integers= 9
total number of floats = 0
total number of pointers= 24
total number of arrays = 16
total number of func types = 6
total number of structs = 7
total number of unions = 2
total number of enums = 0
total number of forward tags= 4
total number of typedefs= 25
total number of volatile types = 0
total number of const types = 4
total number of restrict types = 0
total number of unknowns (holes)= 0
total number of struct members = 64
maximum number of struct members= 25
total size of all structs = 3492
maximum size of a struct= 3156
average number of struct members= 9.14
average size of a struct= 498.86
total number of union members = 6
maximum number of union members = 4
total size of all unions= 132
maximum size of a union = 128
average number of union members = 3.00
average size of a union = 66.00
total number of enum members= 0
maximum number of enum members = 0
total number of unique strings = 112
bytes of string data= 1051
maximum string length = 26
average string length = 9.38
> On a slightly related node, do you know why there is a FreeBSD version ranged
> exclusion around bootstrapping the dtrace tools?
>
> From src/Makefile.inc1:
> # dtrace tools are required for older bootstrap env and cross-build
>
> .if ${MK_CDDL} != "no" && \
>
>((${BOOTSTRAPPING} < 134 && \
>
> !(${BOOTSTRAPPING} >= 901505 && ${BOOTSTRAPPING} < 99)) \
Re: ctfconvert broken for C++ objects?
On Feb 20, 2014, at 10:26 AM, Roman Divacky 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).
On a slightly related node, do you know why there is a FreeBSD version ranged
exclusion around bootstrapping the dtrace tools?
From src/Makefile.inc1:
# dtrace tools are required for older bootstrap env and cross-build
.if ${MK_CDDL} != "no" && \
((${BOOTSTRAPPING} < 134 && \
!(${BOOTSTRAPPING} >= 901505 && ${BOOTSTRAPPING} < 99)) \
|| (${MACHINE} != ${TARGET} || ${MACHINE_ARCH} != ${TARGET_ARCH}))
_dtrace_tools= cddl/usr.bin/sgsmsg cddl/lib/libctf lib/libelf \
lib/libdwarf cddl/usr.bin/ctfconvert cddl/usr.bin/ctfmerge
.endif
We had to disable this protection in our build so that the fixes to the dtrace
tool chain took effect prior to compiling any C++ code during buildworld.
In testing this on head, I also found that 9-stable’s g++ segfaulted when
bootstrapping clang, so I had to buildworld using 9-stable’s clang to get past
the bootstrap phase. (By 9-stable, I mean a 9-stable tree from
October/November from last year).
—
Justin
ctf_for_c++.diffs
Description: Binary data
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: ctfconvert broken for C++ objects?
The dwarf backend for ctfconvert was completely reimplemented a few weeks ago. It's now based on elftoolchain libdwarf. Test on current. On Wed, Feb 19, 2014 at 05:16:35PM -0700, Justin T. Gibbs wrote: > I noticed that ctfmerge was warning about missing CTF data when compiling > ?PROG_CXX? programs. I tracked this down to missing ctfconvert calls when > compiling C++ objects. Unfortunately, ctfconvert segfaults in libdwarf on > all of the C++ code I tried. Attached is a quick hack to avoid the segfault, > but I?m hoping someone here with more dwarf experience can point me in the > right direction for a real fix. Is this a known issue? > > I?m testing this on a FreeBSD stable/9 from ~November of last year. > > Thanks, > Justin > > ___ > freebsd-toolchain@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org" ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: ctfconvert broken for C++ objects?
We're likely to keep hitting these. Ideally, we should replace the libdwarf usage in ctfconvert with either the LLVM or LLDB dwarf parsing, which is getting to be quite mature now and can handle complex encodings. The DWARF5 spec is due out this year and LLVM is already implementing (disabled by default) several of the proposed extensions to DWARF4 that are likely to make it into DWARF5. David On 20 Feb 2014, at 00:16, Justin T. Gibbs wrote: > I noticed that ctfmerge was warning about missing CTF data when compiling > “PROG_CXX” programs. I tracked this down to missing ctfconvert calls when > compiling C++ objects. Unfortunately, ctfconvert segfaults in libdwarf on > all of the C++ code I tried. Attached is a quick hack to avoid the segfault, > but I’m hoping someone here with more dwarf experience can point me in the > right direction for a real fix. Is this a known issue? > > I’m testing this on a FreeBSD stable/9 from ~November of last year. > > Thanks, > Justin > > ___ > freebsd-toolchain@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org" ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
ctfconvert broken for C++ objects?
I noticed that ctfmerge was warning about missing CTF data when compiling “PROG_CXX” programs. I tracked this down to missing ctfconvert calls when compiling C++ objects. Unfortunately, ctfconvert segfaults in libdwarf on all of the C++ code I tried. Attached is a quick hack to avoid the segfault, but I’m hoping someone here with more dwarf experience can point me in the right direction for a real fix. Is this a known issue? I’m testing this on a FreeBSD stable/9 from ~November of last year. Thanks, Justin ctf_for_c++.diffs Description: Binary data ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
