Debugging ports

[Guido Falsi]

On 10/18/2017 06:33, Jan Beich wrote:
> Kubilay Kocak <koobs at FreeBSD.org> writes:
> 
>> On 10/18/17 8:29 AM, Jan Beich wrote:
>>
>>> Guido Falsi <mad at madpilot.net> 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 <mad at madpilot.net>