Re: Building with external toolchain was broken 6 months ago with r255187
Hello, John-Mark.
You wrote 19 марта 2014 г., 2:01:40:
JMG Lev Serebryakov wrote this message on Wed, Mar 19, 2014 at 01:37 +0400:
I did't build my NanoBSD images for almost year, and in this time our
not-finished and fragile support for using external toolchain is rotten,
due to r255187 (and, may meb, some other commits too).
I have very fresh -CURRENT (r263296)
I have these settings for my buildworld buildkernel targets:
XCC=/usr/bin/cc
XCXX=/usr/bin/c++
XCPP=/usr/bin/cpp
XAS=/usr/bin/as
XAR=/usr/bin/ar
XLD=/usr/bin/ld
XNM=/usr/bin/nm
XOBJDUMP=/usr/bin/objdump
XRANLIB=/usr/bin/ranlib
XSTRINGS=/usr/bin/strings
COMPILER_TYPE=clang
WITHOUT_CROSS_COMPILER=yes
WITHOUT_BINUTILS=yes
WITHOUT_CLANG=yes
It worked 7 months ago. Now it works for buildworld but not for
buildkernel:
--- aeskeys_amd64.o ---
/usr/bin/cc --sysroot=/data/obj.nano/gateway.v2/data/src/tmp
-B/data/obj.nano/gateway.v2/data/src/tmp/usr/bin -O2 -pipe
-fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc
-DHAVE_KERNEL_OPTION_HEADERS -include
/data/obj.nano/gateway.v2/data/src/sys/D2500CC/opt_global.h -I. -I@
-I@/contrib/altq -fno-common -g -fno-omit-frame-pointer
-mno-omit-leaf-frame-pointer
-I/data/obj.nano/gateway.v2/data/src/sys/D2500CC -mno-aes -mno-avx
-mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float
-fno-asynchronous-unwind-tables -ffreestanding -fstack-protector
-std=iso9899:1999 -Qunused-arguments -fstack-protector -Wall
-Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes
-Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign
-fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option
-Wno-error-tautological-compare -Wno-error-empty-body
-Wno-error-parentheses-equality -Wno-unused-function-c
/data/src/sys/modules/aesni/../../crypto/aesni/aeskeys_amd64.S
--- aesni_wrap.o ---
In file included from
/data/src/sys/modules/aesni/../../crypto/aesni/aesni_wrap.c:40:
/data/src/sys/modules/aesni/../../crypto/aesni/aesencdec.h:30:10: fatal
error: 'wmmintrin.h' file not found
#include wmmintrin.h
^
1 error generated.
*** [aesni_wrap.o] Error code 1
It could not find header file with intrinsics from system (external)
clang. I could disable building of this module with WITHOUT_MODULES=aesni,
and it works, but what if I need this module?
Could it be fixed, pleeease?
JMG Sounds like your tool chain doesn't have the necessary support for
JMG AES-NI... Are you using gcc as cc? If so, do you have the necessary
JMG tool chain work that I did in r255185 in your local tree?
I use clang from world based on r263296 (amd64) to build world and kernel
from same r263296 (amd64) (as indicated earlier).
JMG Can you compile this test program?
Yes, of course. But kernel and modules are built with -sysroot option,
you know? And my -sysroot doesn't contains clang tree (and
/usr/include/clang/3.4), because it points to fresh world (in
OBJDIRPREFIX) and clang was not built for this world, I'm using system
one. It works for world, GENERIC kernel and all modules but aesni.
JMG -- tsse.c start
JMG #include wmmintrin.h
JMG __m128i foo;
JMG -- tsse.c end --
JMG With the command:
JMG ${XCC} -c -maes tsse.c
JMG If you can't, then the problem is your toolchain, and you need to fix
I can.
JMG it... Try also w/:
JMG clang -c -maes tsse.c
JMG and it's also helpful to know more info, like: ${XCC} --version
/usr/bin/cc --version
FreeBSD clang version 3.4 (tags/RELEASE_34/final 197956) 20140216
Target: x86_64-unknown-freebsd11.0
Thread model: posix
--
// Black Lion AKA Lev Serebryakov l...@freebsd.org
___
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: Building with external toolchain was broken 6 months ago with r255187
Hello, John-Mark. You wrote 19 марта 2014 г., 2:36:38: JMG This still sounds like the compiler being used isn't installed JMG properly... I've never had a problem when a proper kernel-toolchain JMG is available to build the kernel with... JMG If someone is willing to provide me w/ detailed instructions or an image JMG that reproduces the issue, I'm willing to look at it... Try this: /usr/src/tools/tools/nanopbsd/nanobsd.sh -c aesni-problem.nanobsd with attached aesni-problem.nanobsd file. If you add WITHOUT_MODULES=aesni to CONF_WORLD variable it will work. You may want to check first two variables in this script. -- // Black Lion AKA Lev Serebryakov l...@freebsd.org aesni-problem.nanobsd Description: Binary data ___ 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
[RFC] Install world with external toolcahin: need add STRIPBIN to IMAKEENV
Hello, Freebsd-current. To make make installworld successfull with external toolchain (with WITHOUT_BINUTILS-built world) we need to have STRIBIN, pointing to working strip in environment, or install -s will fail. Does attached patch looks good? Unfortunately, STRIP variable is occuped by -s flag :( -- // Black Lion AKA Lev Serebryakov l...@freebsd.org stribin-support-add.patch Description: Binary data ___ 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: FreeBSD GSOC proposal in 2014
Any comments for this thread? There is only three days left for application. If the proposed idea should not be considered in this year, it should be removed from the GSoC idea list and I will submit a different proposal about the CPU hot plug problem in the FreeBSD kernel. Thanks, Yan 2014-03-18 15:39 GMT-04:00 yan cui ccuiy...@gmail.com: Really? Maybe I can download his code from previous GSoC. Actually, before applying for this idea, I did not scan the projects in previous years and just pick up one which I like. Are there any possibilities to improve on this part (or this idea should not be considered any more)? Yan 2014-03-18 14:26 GMT-04:00 John Baldwin j...@freebsd.org: On Friday, March 14, 2014 3:02:18 am Wojciech A. Koszek wrote: On Thu, Mar 13, 2014 at 09:56:35PM -0400, yan cui wrote: Hi all, I write this mail to make my question clear. I know witness can be used to detect wrong lock order in the kernel. However, can it be used to do lock profiling (what I mean is to report the information such as which locks are most contended and print some related statistics such as calling graph, etc)? In other words, is it enough to finish the task by porting witness to the pthread library? Yan, To my knowledge WITNESS is the only tool for lock order verification. For lock profiling in the FreeBSD kernel there's a KTR subsystem. KTR mechanism is basically like syslog() in the user-space, but for the kernel. KTR subsystem will receive messages from KTR API that is placed in the FreeBSD kernel. Messages get stored on the list of some sort. List can be exported to a file. File you can later analyze. Jeff wrote a Python app which can be used for pre-processing the KTR logs from scheduler and protting them visually. Link: http://svnweb.freebsd.org/base/head/tools/sched/schedgraph.py Instead of porting witness to pthreads, maybe we could evaluate expanding WITNESS to cover kern_umtx? This could prove to be more universal. Wojciech There is a dedicated lock profiler (LOCK_PROFILING) in the kernel. A previous GSoC student from an earlier year has already re-implemented both LOCK_PROFILING and WITNESS for pthreads. -- John Baldwin -- Think big; Dream impossible; Make it happen. -- Think big; Dream impossible; Make it happen. ___ 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: [RFC] Install world with external toolcahin: need add STRIPBIN to IMAKEENV
On Mar 19, 2014, at 4:42 AM, Lev Serebryakov l...@freebsd.org wrote: Hello, Freebsd-current. To make make installworld successfull with external toolchain (with WITHOUT_BINUTILS-built world) we need to have STRIBIN, pointing to working strip in environment, or install -s will fail. Assuming you meant STRIPBIN here... Does attached patch looks good? Yes. This looks good to my eye. I have a very similar change in my tree from a while ago where I tried to get external toolchain support working with non-clang compilers. I’ll have to go find that tree… So please go ahead and commit this if you don’t get any objections... Unfortunately, STRIP variable is occuped by -s flag :( A historical accident… but one we’re rather stuck with... Warner ___ 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: FreeBSD GSOC proposal in 2014
On Wed, Mar 19, 2014 at 01:08:58PM -0400, yan cui wrote: Any comments for this thread? There is only three days left for application. If the proposed idea should not be considered in this year, it should be removed from the GSoC idea list and I will submit a different proposal about the CPU hot plug problem in the FreeBSD kernel. Yan, Please submit all possible ideas you have. We'll carefully look into them and judge which one is the most interesting from the FreeBSD point of view. If you were to stay with locking work, given that the work on pthreads was finished, we'd have to look into whether there's anything else to do in this domain. It still can be valuable to perform some improvements, but somebody else with expertise would have to judge. Thanks, Wojciech 2014-03-18 15:39 GMT-04:00 yan cui ccuiy...@gmail.com: Really? Maybe I can download his code from previous GSoC. Actually, before applying for this idea, I did not scan the projects in previous years and just pick up one which I like. Are there any possibilities to improve on this part (or this idea should not be considered any more)? Yan 2014-03-18 14:26 GMT-04:00 John Baldwin j...@freebsd.org: On Friday, March 14, 2014 3:02:18 am Wojciech A. Koszek wrote: On Thu, Mar 13, 2014 at 09:56:35PM -0400, yan cui wrote: Hi all, I write this mail to make my question clear. I know witness can be used to detect wrong lock order in the kernel. However, can it be used to do lock profiling (what I mean is to report the information such as which locks are most contended and print some related statistics such as calling graph, etc)? In other words, is it enough to finish the task by porting witness to the pthread library? Yan, To my knowledge WITNESS is the only tool for lock order verification. For lock profiling in the FreeBSD kernel there's a KTR subsystem. KTR mechanism is basically like syslog() in the user-space, but for the kernel. KTR subsystem will receive messages from KTR API that is placed in the FreeBSD kernel. Messages get stored on the list of some sort. List can be exported to a file. File you can later analyze. Jeff wrote a Python app which can be used for pre-processing the KTR logs from scheduler and protting them visually. Link: http://svnweb.freebsd.org/base/head/tools/sched/schedgraph.py Instead of porting witness to pthreads, maybe we could evaluate expanding WITNESS to cover kern_umtx? This could prove to be more universal. Wojciech There is a dedicated lock profiler (LOCK_PROFILING) in the kernel. A previous GSoC student from an earlier year has already re-implemented both LOCK_PROFILING and WITNESS for pthreads. -- John Baldwin -- Think big; Dream impossible; Make it happen. -- Think big; Dream impossible; Make it happen. -- Wojciech A. Koszek wkos...@freebsd.czest.pl http://FreeBSD.czest.pl/~wkoszek/ ___ 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: March 13: Jenkins and BHyve presentation
On Mon, Feb 24, 2014 at 1:04 AM, Craig Rodrigues rodr...@freebsd.org wrote: The presentation will be on March 13 in Mountain View, California, U.S.A.: http://www.meetup.com/BAFUG-Bay-Area-FreeBSD-User-Group/events/167325932/ Thanks to Annie Zhang and the rest of the iXsystems marketing department who recorded the video and did the editing, the video for this presentation is now online: Go to: https://wiki.freebsd.org/Jenkins#Presentations_and_Working_Groups and click on the link for the video. -- Craig ___ 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
Build failed in Jenkins: FreeBSD_HEAD #312
See https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/312/changes Changes: [imp] Remove redunant declaration. gcc complains while clang doesn't. [imp] Add my humble request for reviews before nanobsd changes happen. -- [...truncated 220061 lines...] ctfconvert -L VERSION -g fb.o --- gui_lib.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-unused-function -nostdinc -I. -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/contrib/altq -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/dev/hptmv/gui_lib.c --- mv.o --- ctfconvert -L VERSION -g mv.o --- hptproc.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-unused-function -nostdinc -I. -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/contrib/altq -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/dev/hptmv/hptproc.c ctfconvert -L VERSION -g hptproc.o --- ioctl.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-unused-function -nostdinc -I. -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/contrib/altq -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/dev/hptmv/ioctl.c --- gui_lib.o --- ctfconvert -L VERSION -g gui_lib.o --- hv_net_vsc.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-unused-function -nostdinc -I. -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/contrib/altq -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/dev/hyperv/netvsc/hv_net_vsc.c --- pmap.o --- ctfconvert -L VERSION -g pmap.o --- hv_net_vsc.o --- ctfconvert -L VERSION -g hv_net_vsc.o --- hv_netvsc_drv_freebsd.o --- cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-unused-function -nostdinc -I.
Re: Hello fdclose
On Wednesday, March 19, 2014 12:38:57 am Warren Block wrote: On Tue, 18 Mar 2014, John Baldwin wrote: On Monday, March 17, 2014 7:23:19 pm Mariusz Zaborski wrote: Hi, After our previous discuss [1] I prepare fdclosedir(3) function which was committed by Pawel (cc'ed) in commit r254499. A while ago I also prepare the fdclose function. Unfortunately, this new function is a little bit more tricky then previous one. Can I ask you for a review of this patch? I think the code is fine. I have a few suggestions on the manpage wording: The +.Fn fdclose +function is equivalent to the +.Fn fclose +function except that this function returns file descriptor instead of +closing it. +.Pp +The I would move fdclose() to its own paragraph and reword this sentence as: The fdclose() function is equivalent to fclose() except that it does not close the underlying file descriptor. .Fn fdclose is equivalent to .Fn fclose , but the file descriptor is returned rather than closed. Likewise in other sections, the markup is supposed to do the job of pointing out that something is a function. Yes, but this has the 'no capital letter at the start of a sentence' problem. Also, I do think reusing the 'underlying file descriptor' language is important in the context of the earlier description of fclose(). -- John Baldwin ___ 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: Hello fdclose
On Wed, 19 Mar 2014, John Baldwin wrote: On Wednesday, March 19, 2014 12:38:57 am Warren Block wrote: On Tue, 18 Mar 2014, John Baldwin wrote: On Monday, March 17, 2014 7:23:19 pm Mariusz Zaborski wrote: Hi, After our previous discuss [1] I prepare fdclosedir(3) function which was committed by Pawel (cc'ed) in commit r254499. A while ago I also prepare the fdclose function. Unfortunately, this new function is a little bit more tricky then previous one. Can I ask you for a review of this patch? I think the code is fine. I have a few suggestions on the manpage wording: The +.Fn fdclose +function is equivalent to the +.Fn fclose +function except that this function returns file descriptor instead of +closing it. +.Pp +The I would move fdclose() to its own paragraph and reword this sentence as: The fdclose() function is equivalent to fclose() except that it does not close the underlying file descriptor. .Fn fdclose is equivalent to .Fn fclose , but the file descriptor is returned rather than closed. Likewise in other sections, the markup is supposed to do the job of pointing out that something is a function. Yes, but this has the 'no capital letter at the start of a sentence' problem. I've heard that mentioned before, but have never seen any actual rule regarding it. And we do have actual rules about avoiding redundant phrases: http://www.freebsd.org/doc/en_US.ISO8859-1/books/fdp-primer/book.html#writing-style-guidelines While normal words should be capitalized as the first word in a sentence, special words that are case-sensitive override that (IMO). Also, I do think reusing the 'underlying file descriptor' language is important in the context of the earlier description of fclose(). Sorry, a problem with my micro-optimization: .Fn fdclose is equivalent to .Fn fclose , but does not close the underlying file descriptor. ___ 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
Jenkins build is back to normal : FreeBSD_HEAD #313
See https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/313/changes ___ 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
gdb problem
I have problem with debug some files compiled with clang, my gbd from system is 6.1.1, like showed. GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as amd64-marcel-freebsd...Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /home2/rizzo/src/Doutorado/main] and when I try to debug a program (main) show this error mesage. What I do wrong? Thanks P.S. the gdb of ports have a compile error, I send a mesage to mainteiner Rizzo ___ 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: gdb problem
On 2014-03-19 23:03, Nilton Jose Rizzo wrote: I have problem with debug some files compiled with clang, my gbd from system is 6.1.1, like showed. GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as amd64-marcel-freebsd...Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /home2/rizzo/src/Doutorado/main] and when I try to debug a program (main) show this error mesage. What I do wrong? Thanks P.S. the gdb of ports have a compile error, I send a mesage to mainteiner Rizzo ___ 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 The debug format changed, so the gdb in base isn't much use anymore. You can try lldb or gdb from ports (when it is fixed). Did you try grabbing the compiled package of gdb from pkgng? -- Allan Jude signature.asc Description: OpenPGP digital signature
