Re: Does "makeoptions WITH_CTF=yes" actually work?
Quoting Navdeep Parhar (from Thu, 22 Apr 2010 01:33:22 -0700): On Thu, Apr 22, 2010 at 09:44:47AM +0200, Alexander Leidinger wrote: Quoting Navdeep Parhar (from Wed, 21 Apr 2010 18:23:33 -0700): >Your patch works for me, thanks. There is just one more problem with the CTF I found a case where it does not work (not kernel related), I have another one which works better. >generation that needs to be fixed: > >http://lists.freebsd.org/pipermail/freebsd-hackers/2009-April/028244.html > >While you're here can you take a look at the patch in that email too? Looks good in concept, but the CTFMERGE line needs the same treatment like all the other ones in the .mk files. I want to commit a suitable change today. Does "same treatment" mean it should run silently too? My personal Yes. opinion is that all ctfconvert and ctfmerge commands should show up in the output of make iff they run. I believe that used to be the case before r206082. Correct, and I agree. The problem is the inverse-logic construct for the check if it shall be run or not which is consistent with all places where this is done. There is no easy way to only display a part of the command which is executed. It was decided by ... (jhb and rwatson?) to not display at all while we still have the default to without ctf (without the @ we will even have some display of something with ctfconvert or ctfmerge in the name, when no ctf info is put into the files). They want to have the default to with ctf when it is ready/stable enough. I assume that at this point the commands get shown again, as the handling of the with/without CTF stuff can be simplified in this case. It is not as easy as all the other with/without stuff we have, due to the fact that parts of the ctf stuff is in sys.mk, which is read before every other file. Currently I want to finish the edge cases we noticed in a *consistent* way, to have something which is giving us stable behavior. After that I will go out of the loop and anyone is free to try/optimize what he wants (as long as I can get a kernel compiled with CTF info without much hassle, I do not care much what is done and how). HTH, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 A hermit is a deserter from the army of humanity. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Does "makeoptions WITH_CTF=yes" actually work?
On Thu, Apr 22, 2010 at 09:44:47AM +0200, Alexander Leidinger wrote: > Quoting Navdeep Parhar (from Wed, 21 Apr 2010 > 18:23:33 -0700): > > >Your patch works for me, thanks. There is just one more problem with the CTF > > I found a case where it does not work (not kernel related), I have > another one which works better. > > >generation that needs to be fixed: > > > >http://lists.freebsd.org/pipermail/freebsd-hackers/2009-April/028244.html > > > >While you're here can you take a look at the patch in that email too? > > Looks good in concept, but the CTFMERGE line needs the same > treatment like all the other ones in the .mk files. I want to commit > a suitable change today. Does "same treatment" mean it should run silently too? My personal opinion is that all ctfconvert and ctfmerge commands should show up in the output of make iff they run. I believe that used to be the case before r206082. Regards, Navdeep ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Does "makeoptions WITH_CTF=yes" actually work?
Quoting Navdeep Parhar (from Wed, 21 Apr 2010 18:23:33 -0700): Your patch works for me, thanks. There is just one more problem with the CTF I found a case where it does not work (not kernel related), I have another one which works better. generation that needs to be fixed: http://lists.freebsd.org/pipermail/freebsd-hackers/2009-April/028244.html While you're here can you take a look at the patch in that email too? Looks good in concept, but the CTFMERGE line needs the same treatment like all the other ones in the .mk files. I want to commit a suitable change today. Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 "I have to get back to New York tomorrow, so think about your price." -- Michael Corleone, "Chapter 27", page 386 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Does "makeoptions WITH_CTF=yes" actually work?
On Fri, Apr 16, 2010 at 03:51:40PM +0200, Alexander Leidinger wrote: > Quoting Navdeep Parhar (from Wed, 14 Apr 2010 > 11:35:40 -0700): > > >Have you or anyone else ever used buildkernel successfully with > >"makeoptions WITH_CTF=yes" in the conf file? Something as simple as > >this does not work for me: > > Copy&paste patch, tabs probbly mangled: > ---snip--- > Index: Makefile.inc1 > === > --- Makefile.inc1 (revision 206700) > +++ Makefile.inc1 (working copy) > @@ -314,7 +314,7 @@ > .endif > > # kernel stage > -KMAKEENV= ${WMAKEENV} > +KMAKEENV= ${WMAKEENV:NNO_CTF=1} > KMAKE= ${KMAKEENV} ${MAKE} KERNEL=${INSTKERNNAME} > > # > @@ -780,7 +780,7 @@ > @echo "--" > cd ${KRNLOBJDIR}/${_kernel}; \ > MAKESRCPATH=${KERNSRCDIR}/dev/aic7xxx/aicasm \ > - ${MAKE} SSP_CFLAGS= -DNO_CPU_CFLAGS -DNO_CTF \ > + ${MAKE} SSP_CFLAGS= -DNO_CPU_CFLAGS \ > -f ${KERNSRCDIR}/dev/aic7xxx/aicasm/Makefile > # XXX - Gratuitously builds aicasm in the ``makeoptions NO_MODULES'' case. > .if !defined(MODULES_WITH_WORLD) && !defined(NO_MODULES) && > exists(${KERNSRCDIR}/modules) > ---snip--- > > This lets the buildkernel generate ctf info in the object files (the > build is not finished yet, so I still have to verify that the final > kernel contains them too, but I do not see a reason ATM why this > should not be the case). Your patch works for me, thanks. There is just one more problem with the CTF generation that needs to be fixed: http://lists.freebsd.org/pipermail/freebsd-hackers/2009-April/028244.html While you're here can you take a look at the patch in that email too? Regards, Navdeep ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Does "makeoptions WITH_CTF=yes" actually work?
Quoting jhell (from Mon, 19 Apr 2010 08:46:33 -0400): [testing CTF] This sounds like a case of too many knobs to control whether ctfconvert will be used on any resulting object code. Couldn't this be better handled by defaulting WITH_CTF:=NO instead of having it act Boolean and set NO_CTF to 0 or 1 but rather check if we are building world or kernel by other means if the user has WITH_CTF defined somewhere else?. Or just check whether WITH_CTF is defined and enable the proper sections of the build for kernel. Sorry, but no. A lot of people tried for doing it by checking if it is defined, but as there is stuff in sys.mk (which is read before everything else), this fails. As I see in sys.mk: stable/7 example and not touched on HEAD. [code in HEAD] Could be simplified: .if defined(WITH_CTF) CTFFLAGS?= -L VERSION CTFCONVERT ?= ctfconvert CTFMERGE?= ctfmerge CTFCONVERT ?= ctfconvert CTFMERGE?= ctfmerge .if defined(CFLAGS) && (${CFLAGS:M-g} != "") CTFFLAGS+= -g .else CFLAGS += -g .endif And this would leave little confusion about what is actually happening and ensure that adding something like (makeoptions -DWITH_CTF) actually work. Try it. The CTF stuff is more complex than it initially looks. I was doing several unsuccesful tries until I arrived at something which works. I do not see a real need for NO_CTF if we can check to see if WITH_CTF is being defined. There is need for it. We have stuff which does not work when compiled with CTF. The current way allows to put some NO_CTF in Makefiles (if we want to), to disable specific problem cases even when the rest is compiled with CTF. I also doubt we want to use the bootblocks or the loader with CTF, so those are items which should get a NO_CTF in any case. For the relevant sections of the tree that should never have WITH_CTF just dont add the ability to check and enable it. Or undefine it. Undefining it would be an option if the default stays off, but there are people which prefer to have the default being on. When the default switches, or the opinion switches to keep the default off, everything needs to be or should be reviewed. Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Does "makeoptions WITH_CTF=yes" actually work?
On 04/16/2010 09:51, Alexander Leidinger wrote: > Quoting Navdeep Parhar (from Wed, 14 Apr 2010 > 11:35:40 -0700): > >> Have you or anyone else ever used buildkernel successfully with >> "makeoptions WITH_CTF=yes" in the conf file? Something as simple as >> this does not work for me: > > Copy&paste patch, tabs probbly mangled: > ---snip--- > Index: Makefile.inc1 > === > --- Makefile.inc1 (revision 206700) > +++ Makefile.inc1 (working copy) > @@ -314,7 +314,7 @@ > .endif > > # kernel stage > -KMAKEENV= ${WMAKEENV} > +KMAKEENV= ${WMAKEENV:NNO_CTF=1} > KMAKE= ${KMAKEENV} ${MAKE} KERNEL=${INSTKERNNAME} > > # > @@ -780,7 +780,7 @@ > @echo > "--" > cd ${KRNLOBJDIR}/${_kernel}; \ > MAKESRCPATH=${KERNSRCDIR}/dev/aic7xxx/aicasm \ > - ${MAKE} SSP_CFLAGS= -DNO_CPU_CFLAGS -DNO_CTF \ > + ${MAKE} SSP_CFLAGS= -DNO_CPU_CFLAGS \ > -f ${KERNSRCDIR}/dev/aic7xxx/aicasm/Makefile > # XXX - Gratuitously builds aicasm in the ``makeoptions NO_MODULES'' case. > .if !defined(MODULES_WITH_WORLD) && !defined(NO_MODULES) && > exists(${KERNSRCDIR}/modules) > ---snip--- > > This lets the buildkernel generate ctf info in the object files (the > build is not finished yet, so I still have to verify that the final > kernel contains them too, but I do not see a reason ATM why this should > not be the case). > > If your build environment is faster (here: about an hour for the > buildkernel), can you please help testing? A buildworld with and without > WITH_CTF in src.conf, and for buildkernel the same (with and without > WITH_CTF in src.conf, and for each with and without makeoptions > WITH_CTF=yes in the kernel). The expected outcome is no CTF when no > WITH_CTF is in src.conf (except for the buildkernel with the > makeoptions), and always with CTF when WITH_CTF is in src.conf > (alternatively only CTF if makeoptions is used, but this would be > surprising for me). > > And then... NO_CTF=yes defined in src.conf and WITH_CTF too... for the > world this should not produce CTF data, but for the kernel I'm not sure > what will or should happen for the makeoptions case... > > Bye, > Alexander. > This sounds like a case of too many knobs to control whether ctfconvert will be used on any resulting object code. Couldn't this be better handled by defaulting WITH_CTF:=NO instead of having it act Boolean and set NO_CTF to 0 or 1 but rather check if we are building world or kernel by other means if the user has WITH_CTF defined somewhere else?. Or just check whether WITH_CTF is defined and enable the proper sections of the build for kernel. As I see in sys.mk: stable/7 example and not touched on HEAD. # Turn CTF conversion off by default for now. This default could be # changed later if DTrace becomes popular. .if !defined(WITH_CTF) NO_CTF = 1 .endif # C Type Format data is required for DTrace CTFFLAGS?= -L VERSION .if !defined(NO_CTF) CTFCONVERT ?= ctfconvert CTFMERGE?= ctfmerge .if defined(CFLAGS) && (${CFLAGS:M-g} != "") CTFFLAGS+= -g .else CFLAGS += -g .endif .endif ### END OF PIECE ### Could be simplified: .if defined(WITH_CTF) CTFFLAGS?= -L VERSION CTFCONVERT ?= ctfconvert CTFMERGE?= ctfmerge CTFCONVERT ?= ctfconvert CTFMERGE?= ctfmerge .if defined(CFLAGS) && (${CFLAGS:M-g} != "") CTFFLAGS+= -g .else CFLAGS += -g .endif And this would leave little confusion about what is actually happening and ensure that adding something like (makeoptions -DWITH_CTF) actually work. I do not see a real need for NO_CTF if we can check to see if WITH_CTF is being defined. For the relevant sections of the tree that should never have WITH_CTF just dont add the ability to check and enable it. Or undefine it. JM2C Regards, -- jhell ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Does "makeoptions WITH_CTF=yes" actually work?
Quoting Navdeep Parhar (from Wed, 14 Apr 2010 11:35:40 -0700): Have you or anyone else ever used buildkernel successfully with "makeoptions WITH_CTF=yes" in the conf file? Something as simple as this does not work for me: Copy&paste patch, tabs probbly mangled: ---snip--- Index: Makefile.inc1 === --- Makefile.inc1 (revision 206700) +++ Makefile.inc1 (working copy) @@ -314,7 +314,7 @@ .endif # kernel stage -KMAKEENV= ${WMAKEENV} +KMAKEENV= ${WMAKEENV:NNO_CTF=1} KMAKE= ${KMAKEENV} ${MAKE} KERNEL=${INSTKERNNAME} # @@ -780,7 +780,7 @@ @echo "--" cd ${KRNLOBJDIR}/${_kernel}; \ MAKESRCPATH=${KERNSRCDIR}/dev/aic7xxx/aicasm \ - ${MAKE} SSP_CFLAGS= -DNO_CPU_CFLAGS -DNO_CTF \ + ${MAKE} SSP_CFLAGS= -DNO_CPU_CFLAGS \ -f ${KERNSRCDIR}/dev/aic7xxx/aicasm/Makefile # XXX - Gratuitously builds aicasm in the ``makeoptions NO_MODULES'' case. .if !defined(MODULES_WITH_WORLD) && !defined(NO_MODULES) && exists(${KERNSRCDIR}/modules) ---snip--- This lets the buildkernel generate ctf info in the object files (the build is not finished yet, so I still have to verify that the final kernel contains them too, but I do not see a reason ATM why this should not be the case). If your build environment is faster (here: about an hour for the buildkernel), can you please help testing? A buildworld with and without WITH_CTF in src.conf, and for buildkernel the same (with and without WITH_CTF in src.conf, and for each with and without makeoptions WITH_CTF=yes in the kernel). The expected outcome is no CTF when no WITH_CTF is in src.conf (except for the buildkernel with the makeoptions), and always with CTF when WITH_CTF is in src.conf (alternatively only CTF if makeoptions is used, but this would be surprising for me). And then... NO_CTF=yes defined in src.conf and WITH_CTF too... for the world this should not produce CTF data, but for the kernel I'm not sure what will or should happen for the makeoptions case... Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 See, these two penguins walked into a bar, which was really stupid, 'cause the second one should have seen it. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Does "makeoptions WITH_CTF=yes" actually work?
Quoting Navdeep Parhar (from Wed, 14 Apr 2010 11:35:40 -0700): On Wed, Apr 14, 2010 at 01:23:42PM +0200, Alexander Leidinger wrote: Quoting Navdeep Parhar (from Wed, 14 Apr 2010 02:31:30 -0700): >On Wed, Apr 14, 2010 at 1:58 AM, Alexander Leidinger > wrote: >>Quoting Navdeep Parhar (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). Have you or anyone else ever used buildkernel successfully with "makeoptions WITH_CTF=yes" in the conf file? Something as simple as this does not work for me: - pristine sources in /usr/src, empty /usr/obj, no /etc/make.conf, no /etc/src.conf - add "makeoptions WITH_CTF=yes" in sys/amd64/conf/GENERIC - make buildkernel in /usr/src I can reproduce what you see. Somewhere NO_CTF is feed to the build of the kernel. I will have a look from where this comes. Until then I suggest to compile the kernel by hand (if you want to make use of the CTF stuff) instead of using buildkernel. Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 I attribute my success to intelligence, guts, determination, honesty, ambition, and having enough money to buy people with those qualities. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Does "makeoptions WITH_CTF=yes" actually work?
On Wed, Apr 14, 2010 at 01:23:42PM +0200, Alexander Leidinger wrote: > Quoting Navdeep Parhar (from Wed, 14 Apr 2010 > 02:31:30 -0700): > > >On Wed, Apr 14, 2010 at 1:58 AM, Alexander Leidinger > > wrote: > >>Quoting Navdeep Parhar (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). Have you or anyone else ever used buildkernel successfully with "makeoptions WITH_CTF=yes" in the conf file? Something as simple as this does not work for me: - pristine sources in /usr/src, empty /usr/obj, no /etc/make.conf, no /etc/src.conf - add "makeoptions WITH_CTF=yes" in sys/amd64/conf/GENERIC - make buildkernel in /usr/src The result is a kernel without CTF information. The log is at http://www.freebsd.org/~np/WITH_CTF.log Regards, Navdeep ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Does "makeoptions WITH_CTF=yes" actually work?
Quoting Navdeep Parhar (from Wed, 14 Apr 2010 02:31:30 -0700): On Wed, Apr 14, 2010 at 1:58 AM, Alexander Leidinger wrote: Quoting Navdeep Parhar (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 @ 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 @'s? I did a "objdump -h *.o | grep SUNW_ctf" and I get a lot of ctf sections displayed. Adding the @ 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 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 @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 THE DAILY PLANET SUPERMAN SAVES DESSERT! Plans to "Eat it later" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Does "makeoptions WITH_CTF=yes" actually work?
On Wed, Apr 14, 2010 at 1:58 AM, Alexander Leidinger wrote: > Quoting Navdeep Parhar (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 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. > ---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 @ 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. [ -z "${CTFCONVERT}" -o -n "${NO_CTF}" ] || ${CTFCONVERT} ${CTFFLAGS} ${.TARGET} [ -z "ctfconvert" -o -n "1" ] || Do you see anything different if you remove all the @'s? > 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 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 Regards, Navdeep > > Bye, > Alexander. > > -- > http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 > http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 > The Force is what holds everything together. > It has its dark side, and it has its light side. > It's sort of like cosmic duct tape. > > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Does "makeoptions WITH_CTF=yes" actually work?
Quoting Navdeep Parhar (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 ---snip--- I built the kernel with a "make -j16 buildkernel" in /usr/src. How do you determine if ctfconvert is run or not? 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 and have a look if the .SUNW_ctf section is there to determine if CTF stuff was inserted or not. Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 The Force is what holds everything together. It has its dark side, and it has its light side. It's sort of like cosmic duct tape. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"