Quoting Navdeep Parhar <nparhar_at_gmail.com> (from Wed, 14 Apr 2010 02:31:30 -0700): > On Wed, Apr 14, 2010 at 1:58 AM, Alexander Leidinger > <netchild_at_freebsd.org> wrote: >> Quoting Navdeep Parhar <nparhar_at_gmail.com> (from Wed, 14 Apr 2010 01:33:29 >> -0700): >> >>> I read the UPDATING entry that accompanied r206082 and added WITH_CTF=yes >>> to >>> my kernel config, hoping to get CTF information in the kernel and all >>> modules. No luck. >>> It appears that NO_CTF remains set to 1 inspite of the undef NO_CTF in >>> various .mk files >>> and ctfconvert never runs. >> >> This is the output I get in my kernel build directory: >> ---snip--- >> # make -V NO_CTF -V WITH_CTF >> >> yes > > Can you also try a "makeoptions WITH_CTF=yes" in your KERNCONF The above one is with WITH_CTF in my kernel config, but this was generated manually with cd /sys/i386/conf; config CONF; cd ../compile/CONF; make -V... > and see if the results are as expected? How was r206082 tested? I'm > trying to figure out the differences, if any, between your build setup and > mine. I made a buildworld with and without WITH_CTF in src.conf to confirm that it works (no installkernel, as the world is known to be not useable with CTF), and I did a lot of tests by hand as above (config;make). >> ---snip--- >> >>> I built the kernel with a "make -j16 buildkernel" in /usr/src. >> >> How do you determine if ctfconvert is run or not? > > I got rid of the _at_ in front of all the CTF commands in all the .mk files. I > could see that NO_CTF was 1 and so the ctfconvert after || wouldn't > run. Can it be that NO_CTF is somewhere, e.g. in src.conf or make.conf or in the environment of the shell? Did you do an installworld before? The installworld is maybe important, I do not have in mind if /ush/share/mk/ or SRC/share/mk is used and as such the NO_CTF which was before in /usr/share/mk/* could cause what you see. > [ -z "${CTFCONVERT}" -o -n "${NO_CTF}" ] || ${CTFCONVERT} > ${CTFFLAGS} ${.TARGET} > > [ -z "ctfconvert" -o -n "1" ] || ........ > > Do you see anything different if you remove all the _at_'s? I did a "objdump -h *.o | grep SUNW_ctf" and I get a lot of ctf sections displayed. Adding the _at_ in front was the last action I did, before that every case was working correctly. >> If you expect to see >> ctfconvert lines in the build output: this will not be the case, no matter >> if you enable it or not. With the current way of handling it, I'm not aware >> of a way how to print the command when ctfconvert is really executed (we can >> maybe add an echo which prints out something, but the question is if this is >> worth the effort). >> >> You can run objdump -f <objectfile> and have a look if the .SUNW_ctf section >> is there to determine if CTF stuff was inserted or not. > > I tried this: > # ctfdump /usr/obj/usr/src/sys/GENERIC/kernel > /usr/obj/usr/src/sys/GENERIC/kernel does not contain .SUNW_ctf data That's a lot of output (that I get when I do it on my kernel which was build with makeoptions WITH_CTF=yes), if you just want to know if there is or is not ctf data in the kernel, the objdump (with -h, and not -f as I wrote above) gives just one line if ctf date is present. Bye, Alexander. -- http://www.Leidinger.net Alexander _at_ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild _at_ FreeBSD.org : PGP ID = 72077137 THE DAILY PLANET SUPERMAN SAVES DESSERT! Plans to "Eat it later"Received on Wed Apr 14 2010 - 09:23:53 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:02 UTC