Re: Debugging ports
Well, 11-STABLE now has LLVM 5.0 too, so it should work as well as in head. I actually tried it on the recent 11-STABLE. On 17-10-18 10:03:49, Guido Falsi wrote: On 10/18/2017 09:59, Piotr Kubaj wrote: According to https://wiki.freebsd.org/lldb, it should work just fine on amd64, apart from kernel debugger. I suppose there should be some improvements for other archs too, since that page was updated 1.5 years ago :) Great! And good to know, I'll give it a spin the next time I need to debug something on head :) -- Guido Falsi-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- _ / All Gods were immortal. \ | | \ -- Stanislaw J. Lec, "Unkempt Thoughts" / - \ ^__^ \ (oo)\___ (__)\ )\/\ ||w | || || signature.asc Description: PGP signature
Re: Debugging ports
On 10/18/2017 09:59, Piotr Kubaj wrote: > According to https://wiki.freebsd.org/lldb, it should work just fine on > amd64, apart from kernel debugger. I suppose there should be some > improvements for other archs too, since that page was updated 1.5 years > ago :) Great! And good to know, I'll give it a spin the next time I need to debug something on head :) -- Guido Falsi___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Debugging ports
According to https://wiki.freebsd.org/lldb, it should work just fine on amd64, apart from kernel debugger. I suppose there should be some improvements for other archs too, since that page was updated 1.5 years ago :) On 17-10-18 09:54:05, Guido Falsi wrote: On 10/18/2017 09:52, Piotr Kubaj wrote: Shouldn't lldb be the replacement for gdb in base? I'm not keeping an eye on that, but I don't think it's ready at present. -- Guido Falsi-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- _ / Due to lack of disk space, this fortune \ \ database has been discontinued. / - \ ^__^ \ (oo)\___ (__)\ )\/\ ||w | || || signature.asc Description: PGP signature
Re: Debugging ports
On 10/18/2017 09:52, Piotr Kubaj wrote: > Shouldn't lldb be the replacement for gdb in base? I'm not keeping an eye on that, but I don't think it's ready at present. -- Guido Falsi___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Debugging ports
Shouldn't lldb be the replacement for gdb in base? On 17-10-18 09:47:25, Guido Falsi wrote: On 10/18/2017 06:33, Jan Beich wrote: Kubilay Kocakwrites: On 10/18/17 8:29 AM, Jan Beich wrote: Guido Falsi writes: On 10/17/2017 23:11, Guido Falsi wrote: Thing is, recompiling with WITH_DEBUG doesn't help (I only get memory addresses in gdb), nor does -DCMAKE_BUILD_TYPE=Debug to CMAKE_ARGS (the port uses CMake). Sorry, I clearly did not parse your message correctly. Looks strange though, WITH_DEBUG always worked for me... Usually I compile the whole set in poudriere with WITH_DEBUG, to make sure all libraries have symbols too. WITH_DEBUG doesn't disable vendor optimizations like -fomit-frame-pointer which may hinder stack unwinding, doesn't enable debug symbols for ports not respecting CFLAGS, often a nop for non-C/C++ ports, etc. Could the framework WITH_DEBUG block remove this (and potentially) other relevant flags from C*FLAGS if present with variable modifiers? Only for what make(1) inherits when Mk/bsd.port.mk is parsed. A lot more ports pass the option via makefiles under WRKSRC that cannot be altered short of patching or overriding all CFLAGS. To get accurate list of offenders an -exp run WITH_DEBUG=1 is required then grep(1) build logs for -fomit-frame-pointer and -O* flags. This can result in bugs against ports that fail to properly respect CFLAGS, so the port maintainers can help with patches. I'm preparing a patch related to WITH_DEBUG, which, if accepted, will need an exp-run before going in. That would be a good chance to perform a check for these kind of things. But I'm still working on it and will need a little more time. I'll let you know as soon as I have something I am willing to show. BTW on head gdb is gone from base for i386/amd64 AFAIK, so ports gdb will be the only way to go in the future. -- Guido Falsi -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- / The student in question is performing \ | minimally for his peer group and is an | \ emerging underachiever./ \ ^__^ \ (oo)\___ (__)\ )\/\ ||w | || || signature.asc Description: PGP signature
Re: Debugging ports
On 10/18/2017 06:33, Jan Beich wrote: > Kubilay Kocakwrites: > >> On 10/18/17 8:29 AM, Jan Beich wrote: >> >>> Guido Falsi writes: >>> On 10/17/2017 23:11, Guido Falsi wrote: >> >> Thing is, recompiling with WITH_DEBUG doesn't help (I only get >> memory addresses in gdb), nor does -DCMAKE_BUILD_TYPE=Debug to >> CMAKE_ARGS (the port uses CMake). Sorry, I clearly did not parse your message correctly. Looks strange though, WITH_DEBUG always worked for me... Usually I compile the whole set in poudriere with WITH_DEBUG, to make sure all libraries have symbols too. >>> >>> WITH_DEBUG doesn't disable vendor optimizations like -fomit-frame-pointer >>> which may hinder stack unwinding, doesn't enable debug symbols for ports >>> not respecting CFLAGS, often a nop for non-C/C++ ports, etc. >> >> Could the framework WITH_DEBUG block remove this (and potentially) other >> relevant flags from C*FLAGS if present with variable modifiers? > > Only for what make(1) inherits when Mk/bsd.port.mk is parsed. A lot more > ports pass the option via makefiles under WRKSRC that cannot be altered > short of patching or overriding all CFLAGS. > > To get accurate list of offenders an -exp run WITH_DEBUG=1 is required > then grep(1) build logs for -fomit-frame-pointer and -O* flags. This can > result in bugs against ports that fail to properly respect CFLAGS, so the > port maintainers can help with patches. I'm preparing a patch related to WITH_DEBUG, which, if accepted, will need an exp-run before going in. That would be a good chance to perform a check for these kind of things. But I'm still working on it and will need a little more time. I'll let you know as soon as I have something I am willing to show. BTW on head gdb is gone from base for i386/amd64 AFAIK, so ports gdb will be the only way to go in the future. -- Guido Falsi ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Debugging ports
Kubilay Kocakwrites: > On 10/18/17 8:29 AM, Jan Beich wrote: > >> Guido Falsi writes: >> >>> On 10/17/2017 23:11, Guido Falsi wrote: >>> > > Thing is, recompiling with WITH_DEBUG doesn't help (I only get > memory addresses in gdb), nor does -DCMAKE_BUILD_TYPE=Debug to > CMAKE_ARGS (the port uses CMake). >>> >>> Sorry, I clearly did not parse your message correctly. >>> >>> Looks strange though, WITH_DEBUG always worked for me... Usually I >>> compile the whole set in poudriere with WITH_DEBUG, to make sure all >>> libraries have symbols too. >> >> WITH_DEBUG doesn't disable vendor optimizations like -fomit-frame-pointer >> which may hinder stack unwinding, doesn't enable debug symbols for ports >> not respecting CFLAGS, often a nop for non-C/C++ ports, etc. > > Could the framework WITH_DEBUG block remove this (and potentially) other > relevant flags from C*FLAGS if present with variable modifiers? Only for what make(1) inherits when Mk/bsd.port.mk is parsed. A lot more ports pass the option via makefiles under WRKSRC that cannot be altered short of patching or overriding all CFLAGS. To get accurate list of offenders an -exp run WITH_DEBUG=1 is required then grep(1) build logs for -fomit-frame-pointer and -O* flags. This can result in bugs against ports that fail to properly respect CFLAGS, so the port maintainers can help with patches. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Debugging ports
On 10/18/17 8:29 AM, Jan Beich wrote: > Guido Falsiwrites: > >> On 10/17/2017 23:11, Guido Falsi wrote: >> Thing is, recompiling with WITH_DEBUG doesn't help (I only get memory addresses in gdb), nor does -DCMAKE_BUILD_TYPE=Debug to CMAKE_ARGS (the port uses CMake). >> >> Sorry, I clearly did not parse your message correctly. >> >> Looks strange though, WITH_DEBUG always worked for me... Usually I >> compile the whole set in poudriere with WITH_DEBUG, to make sure all >> libraries have symbols too. > > WITH_DEBUG doesn't disable vendor optimizations like -fomit-frame-pointer > which may hinder stack unwinding, doesn't enable debug symbols for ports > not respecting CFLAGS, often a nop for non-C/C++ ports, etc. Could the framework WITH_DEBUG block remove this (and potentially) other relevant flags from C*FLAGS if present with variable modifiers? > Without an example it's hard to guess. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Debugging ports
I think I got it. It turns out that it's our gdb in base that can't read the debug info. lldb and gdb from ports do it just fine. I also thought about recompiling library dependecies, but something didn't fit in, because not only the libraries calls were not there, but the calls from the port itself as well. Thanks anyway! On 17-10-17 23:29:47, Jan Beich wrote: Guido Falsiwrites: On 10/17/2017 23:11, Guido Falsi wrote: Thing is, recompiling with WITH_DEBUG doesn't help (I only get memory addresses in gdb), nor does -DCMAKE_BUILD_TYPE=Debug to CMAKE_ARGS (the port uses CMake). Sorry, I clearly did not parse your message correctly. Looks strange though, WITH_DEBUG always worked for me... Usually I compile the whole set in poudriere with WITH_DEBUG, to make sure all libraries have symbols too. WITH_DEBUG doesn't disable vendor optimizations like -fomit-frame-pointer which may hinder stack unwinding, doesn't enable debug symbols for ports not respecting CFLAGS, often a nop for non-C/C++ ports, etc. Without an example it's hard to guess. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- _ / If a camel is a horse designed by a \ | committee, then a consensus forecast is | | a camel's behind. | | | \ -- Edgar R. Fiedler / - \ ^__^ \ (oo)\___ (__)\ )\/\ ||w | || || signature.asc Description: PGP signature
Re: Debugging ports
Guido Falsiwrites: > On 10/17/2017 23:11, Guido Falsi wrote: > >>> >>> Thing is, recompiling with WITH_DEBUG doesn't help (I only get >>> memory addresses in gdb), nor does -DCMAKE_BUILD_TYPE=Debug to >>> CMAKE_ARGS (the port uses CMake). > > Sorry, I clearly did not parse your message correctly. > > Looks strange though, WITH_DEBUG always worked for me... Usually I > compile the whole set in poudriere with WITH_DEBUG, to make sure all > libraries have symbols too. WITH_DEBUG doesn't disable vendor optimizations like -fomit-frame-pointer which may hinder stack unwinding, doesn't enable debug symbols for ports not respecting CFLAGS, often a nop for non-C/C++ ports, etc. Without an example it's hard to guess. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Debugging ports
On 10/17/2017 23:11, Guido Falsi wrote: Thing is, recompiling with WITH_DEBUG doesn't help (I only get memory addresses in gdb), nor does -DCMAKE_BUILD_TYPE=Debug to CMAKE_ARGS (the port uses CMake). Sorry, I clearly did not parse your message correctly. Looks strange though, WITH_DEBUG always worked for me... Usually I compile the whole set in poudriere with WITH_DEBUG, to make sure all libraries have symbols too. -- Guido Falsi___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Debugging ports
Piotr Kubaj via freebsd-portswrites: > Hi all, > > I am preparing a new port. However, I hit an assertion fail when > starting the binary. The developer is willing to help me, provided > that I send him backtrace and values from the structure that hits > assertion failure. > > Thing is, recompiling with WITH_DEBUG doesn't help (I only get memory > addresses in gdb), nor does -DCMAKE_BUILD_TYPE=Debug to CMAKE_ARGS > (the port uses CMake). > > What should I do to get necessary date? Recompile library dependencies (look up which via ldd(1) and strings(1)) with debugging symbols as well. That may include not only ports but some of the base e.g., lib/libc, lib/libthr, libexec/rtld-elf. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Debugging ports
On 10/17/2017 18:04, Piotr Kubaj via freebsd-ports wrote: Hi all, I am preparing a new port. However, I hit an assertion fail when starting the binary. The developer is willing to help me, provided that I send him backtrace and values from the structure that hits assertion failure. Thing is, recompiling with WITH_DEBUG doesn't help (I only get memory addresses in gdb), nor does -DCMAKE_BUILD_TYPE=Debug to CMAKE_ARGS (the port uses CMake). What should I do to get necessary date? You should add "WITH_DEBUG=yes" in your make.conf file, then recompile any port in which you need debugging symbols. It will automatically disable optimizations, add -g to CFLAGS and add many other common knobs for any port. Most ports needing special care to get debugging binaries have extra directives in their Makefiles, enabled by that same flag. Be aware that compiling a debugging version requires more memory than a normal version, for big ports it could get REALLY big. I was not able to compile a debugging version of llvm40 with 16 GiB RAM (one poudriere jail using make jobs, maybe without parallelization it could be done). If you're using poudriere to build a whole set of ports you could use something like this (verbatim from my machine): WITH_DEBUG= yes .if ${.CURDIR:M*lang/ruby*} || ${.CURDIR:M*devel/llvm*} || ${.CURDIR:M*lang/gcc*} || ${.CURDIR:M*devel/gdb*} || ${.CURDIR:M*www/webkit*} .undef WITH_DEBUG .endif (obviously I'm not debugging any of those which are quite memory hungry when building debugging versions, but I'm debugging other things depending on them) Hope this helps. -- Guido Falsi___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"