[Ffmpeg-devel] Re: [BUG] Compilation failure when using --disable-opts

[Måns Rullgård]

Panagiotis Issaris <takis at issaris.org> writes:

> Hi M?ns,
>
> M?ns Rullg?rd schreef:
>> Diego Biurrun <diego at biurrun.de> writes:
>>> On Thu, Mar 15, 2007 at 08:03:58PM -0300, Ramiro Polla wrote:
>>>> M?ns Rullg?rd escreveu:
>>>>> Panagiotis Issaris <takis at issaris.org> writes:
>>>>>  
>>>>>> Sure. Although I wonder: Doesn't anybody in here use a debugger? Aren't
>>>>>> you annoyed by the jumping around because of reorderings caused by the
>>>>>> compilers' optimizations?
>>>>> That's what makes debugging fun.  It gets even better on MIPS with
>>>>> delayed branching...
>>>>>
>>>>> Actually, I don't use debuggers a whole lot.  I find a generous
>>>>> measure of printf works much better in most cases.
>>>> You should try Microsoft Visual Studio =) It will totally change your 
>>>> debugging experience.
>>>>
>>>> (yes, I know. It doesn't debug .stabs..)
>>> IIRC Mans knows Visual Studio.
>> 
>> I have probably used more debuggers than most of you, none of them
>> particularly impressive, and Visual Studio worse than most.
>> 
>> What I'm trying to get at is that a debugger might often let you see a
>> snapshot of the process state whenever you stop it, typically at a
>> breakpoint.  What it will not do is tell you how the process got into
>> that state.  Placing print statements in strategic places will produce
>> a log telling you exactly what has happened.  The trick is in printing
>> the right information at the right places.
> There's tracepoints for that.

I personally find it much simpler to write a printf statement than
configure a debugger to spit out the same information.

>> Before you ask, I know single-stepping is possible.  It's just not
>> practical to single-step for three days waiting for the special
>> condition to arise, at the same time mentally tracking the state in
> You can use conditional breakpoints for that :)

Conditional breakpoints still don't give you the history.  They also
interfere with execution, since the process is stopped and conditions
evaluated each time a breakpoint is encountered.  This has a much
higher overhead than a conditional print statement, and is again much
more tedious to configure.

>> some vain hope to spot the point where things go wrong.  Debuggers
>> can also interfere with the execution, especially timing, in ways that
>> might cause the bug to never manifest itself.
> This is IMHO the most problematic thing with debuggers. But if timing
> isn't concerned debuggers are useful (again IMHO).

As I said, you are entitled to your opinion.  I still say that 99% of
what can be done with a debugger can be done more easily with printf.
For the remaining 1% I'll happily use a debugger.  It's all about
using the appropriate tool for the job.

-- 
M?ns Rullg?rd
mans at mansr.com