This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
Re: tdep/2305: IA64: breakpoints on predicated instructions ignorepredicate
- From: Daniel Jacobowitz <drow at false dot org>
- To: nobody at sources dot redhat dot com
- Cc: gdb-prs at sources dot redhat dot com,
- Date: 29 Aug 2007 18:28:01 -0000
- Subject: Re: tdep/2305: IA64: breakpoints on predicated instructions ignorepredicate
- Reply-to: 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