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 21:18: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 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