This is the mail archive of the gdb-patches@sourceware.cygnus.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Merge of ARM Linux port with existing ARM code...


Stan Shebs wrote:
> 
> You're right about the size of the descrepancy between -O0 and -O2,
> but I think it's going a bit far to say "there is no point in
> debugging unoptimized code".  Almost all of my own debugging work is
> done on unoptimized code.

I agree with you in fact.  But in many cases when I had problems they
only occurred in optimized code.   The problem goes away or never
occurred in unoptimized code.  Which was really the point I wanted to
make.

> GDB's official position on optimized code is to allow the debugger to
> work with it, but not to promise very much functionality.  -O2 in GCC
> includes ever-more-aggressive optimizations, and it's going to be hard
> or impossible for GDB to reconstruct the original code in all cases.
> Conditional moves are a primo example - you have a single instruction
> that is an amalgam of several source lines, and you want GDB to
> present the illusion that it can do several statement-level steps,
> when the actual hardware will do only one instruction-level step.  For
> GDB, an instruction-level step is an atomic operation.  How do you
> divide up an atom?  (Use a cyclotron, of course :-) )

The problem is much more general on the ARM.  Every instruction is
conditional, or can be anyway.  If you put a breakpoint on such an
instruction the breakpoint is executed unconditionally currently even if
the execution is conditional.  If you ignore high level languages
altogether and assume only assembler source.

cmp 	r0, #0
suble	r1, r2, r3
addgt	r1, r2, r3

If the above construct is part of a loop, placing a breakpoint on the
subtraction operation causes it to break once per loop.  What if you are
only interested in the case when the instruction is actually executed? 
Say it is only executed once in a million iterations of the loop.  You
can hit a lot of breakpoints before you get to the point the instruction
is actually executed.  Why not let the CPU decide if a breakpoint is
required by using the condition predicate for the instruction in the
breakpoint instruction?

Scott

-- 
Scott Bambrough - Software Engineer
REBEL.COM    http://www.rebel.com
NetWinder    http://www.netwinder.org

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]