[PATCH RFA] step-test.exp changes for IA-64
Mon May 15 11:39:00 GMT 2000
On May 13, 7:58am, Michael Snyder wrote:
> Kevin Buettner wrote:
> > This patch was applied earlier today. At Fernando's request, I added
> > some additional comments describing the reason for the different behavior
> > on the IA-64.
> > On Apr 25, 8:42pm, Kevin Buettner wrote:
> > > Subject: [PATCH RFA] step-test.exp changes for IA-64
> > > I request approval for committing the changes below.
> > >
> > > On IA-64, when using "finish" to step out of a function, gdb will stop
> > > on the line containing the call to the function that you've just
> > > stepped out of. The reason for this is that immediately after the
> > > call instruction is an instruction which restores the global pointer.
> > > Since this is part of the sequence of instructions forming the call,
> > > it makes sense that gdb would place you on the line of the call instead
> > > of the next executable line after the call.
> Such behavior is not all that unusual. It might be good to
> generalize the test so that it accepts either the line with
> the function call or the line after, instead of making it
> depend on a specific target.
I'm certainly willing to do this if acceptable to the testsuite
maintainers. Fernando, at least, had certain reservations about this
patch to begin with. (See the "What should `finish' do?" thread.)
It seems to me that we could arrange to skip the instructions which
restore the caller-save variables which occur immediately after the
call instruction. For the testsuite, at least, that would put us
on a different line so that the testsuite would (probably) work.
OTOH, it is a valid question to ask whether it's really worth it.
I.e, do gdb users ever get confused by the present behavior? If the
answer is no, I think it's better to make the testsuite handle either
the case of `finish' stopping on the next line following the call or
on the line of the call itself. If yes, then we should make an effort
to skip the instructions which form part of the call itself so that
gdb stops on the line after the call. (I have a hard time answering
this question myself, because, at the moment, I don't find it
confusing to see gdb stop on the line of the call itself. OTOH, I
don't remember if I was confused or not the first time I saw this
More information about the Gdb-patches