This is the mail archive of the gdb-prs@sourceware.org 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]
Other format: [Raw text]

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


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 17:10:04 -0400

 On Wed, Aug 29, 2007 at 02:59:37PM -0600, John S. Worley wrote:
 > > Stopping on line 91 (i.e., arbitrarily far earlier) is unacceptable.
 > >   
 >    Why?
 
 Because if you do this, most of your breakpoints are going to end up
 at a load of 0 into a register at the very beginning of your function.
 
 GDB has to do the best it can with optimized code.  This relies on
 both GDB and GCC making intelligent decisions about what is
 "interesting".  Jim Blandy had some proposals to do this in more
 depth, focusing on expressions with user-visible side effects
 (like the stores to z and a).  I don't know if they'll ever come
 to be.
 
 >    With a breakpoint set at 112, is completely unexpected, confusing, 
 > time-consuming, and just plain wrong.
 
 I didn't say that it was right.  I said that changing this wrong
 behavior for the other wrong behavior was much worse.
 
 > > It has very little to do with IA-64 and we have discussed it before in
 > > ARM and other contexts.
 > >   
 >    It has a lot to do with IA64, since it's parallelism and rich predication 
 > calculus are changing the
 > rules and challenging conventional wisdoms about assembly programming and 
 > compilation.
 
 I am heartily sick of hearing about how new, unique, and original IA64
 is.  Predication, _and the problems of debugging it_, are not new and
 have been discussed before.
 
 > > 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.
 > >
 > >   
 >    Stopping more often is not a better choice, just a simpler one.
 
 Disagree based on six years of GDB maintenance.
 
 > I suggest 
 > there is a need for both
 > types of breakpoints, at a minimum because single stepping at the instruction 
 > level requires it. I would
 > accept the argument that the false stop problem may require action on the 
 > user's part, such as a
 > IA64-only command like 'breaki' to insert breakpoints that honor the predicate. 
 > Is there a  guide for
 > adding architecture-dependent commands to GDB?
 
 No.  It probably shouldn't be architecture-dependent, though.  Again,
 this is not unique to IA-64.
 
 You may wish to take this discussion to the GDB mailing list, as it
 requires some amount of design to figure out what would be useful and
 whether we have better, automatic solutions available.
 
 -- 
 Daniel Jacobowitz
 CodeSourcery


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