Re: tdep/2305: IA64: breakpoints on predicated instructions ignorepredicate

[Daniel Jacobowitz <drow at false dot org>]

The following reply was made to PR tdep/2305; it has been noted by GNATS.

From: Daniel Jacobowitz <drow@false.org>
To: "John S. Worley" <jsworley@qwest.net>
Cc: gdb-gnats@sources.redhat.com
Subject: Re: tdep/2305: IA64: breakpoints on predicated instructions ignore
	predicate
Date: Wed, 29 Aug 2007 14:27:17 -0400

 On Wed, Aug 29, 2007 at 11:58:41AM -0600, John S. Worley wrote:
 > Daniel -
 > 
 >    Thanks for the reply. I don't agree that using conditional breakpoints is 
 > equivalent,
 
 I never said it was equivalent.  It is the practical option.
 
 It would also be possible to implement an optimization in GDB where it
 uses conditional breakpoint instructions.
 
 > 
 >    In terms of "generally expected" behavior, I don't agree with your example: 
 > in this case,
 > you can and should set the breakpoint on the instruction with computes the 'a 
 > == b'
 > predicate.
 
 No way.  You're thinking from the perspective of a user who can look
 at the generated instructions and draw some sensible conclusion.
 Consider:
 
 91	z = b ? x : y;
 92	a = b ? c : d;
 
 Optimized to set a predicate in line 91, and then four conditional
 moves (probably in only two bundles).
 	  
 The user clicks on line 92 in their IDE.  GDB should stop on line 92.
 Stopping on line 91 (i.e., arbitrarily far earlier) is unacceptable.
 Stopping only when the predicate is true is also unacceptable.
 
 >    in parallel with other independent instructions. Setting a breakpoint at the 
 > assignment statement
 > in GDB will break every time through the code, even when ptr == NULL, which is 
 > certainly *NOT
 > *the expected (or reasonable) behavior.
 
 Yes.  This is one of the hard problems in debuggering optimized code.
 It has very little to do with IA-64 and we have discussed it before in
 ARM and other contexts.
 
 Using a conditional breakpoint is only reasonable if the compiler
 indicates in debug info that the line is predicated.  No compiler that
 I know of generates such information and doing so in an optimizing
 compiler is quite hard.
 
 I'm not interested in trading unexpected stops for unexpected failures
 to stop.  Experience has definitely shown that when we can't get it
 right, stopping more often is better than less often.
 
 -- 
 Daniel Jacobowitz
 CodeSourcery