Re: Debugging ports

2017-10-18 Thread Piotr Kubaj via freebsd-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

2017-10-18 Thread Guido Falsi 
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

2017-10-18 Thread Piotr Kubaj via freebsd-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

2017-10-18 Thread Guido Falsi 
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

2017-10-18 Thread Piotr Kubaj via freebsd-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 Kocak  writes:


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

2017-10-18 Thread Guido Falsi 
On 10/18/2017 06:33, Jan Beich wrote:
> Kubilay Kocak  writes:
> 
>> 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

2017-10-17 Thread Jan Beich 
Kubilay Kocak  writes:

> 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

2017-10-17 Thread Kubilay Kocak 
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?

> 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

2017-10-17 Thread Piotr Kubaj via freebsd-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 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.

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

2017-10-17 Thread Jan Beich 
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.

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

2017-10-17 Thread Guido Falsi 

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

2017-10-17 Thread Jan Beich 
Piotr Kubaj via freebsd-ports  writes:

> 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

2017-10-17 Thread Guido Falsi 

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"