Unable to step over (n and ni) on mipsel-linux...

Unable to step over (n and ni) on mipsel-linux...

[David Daney]

GNU gdb 6.2_2004-08-19-cvs

from the gdb_6_2-branch yesterday.

../gdbcvs/src/configure  --build=i686-pc-linux --host=mipsel-linux
--target=mipsel-linux --enable-tui=no

Most of the time when I do next or nexti, gdb is treating it as if I did
step or stepi.

I have tracked the problem down to this portion of code:

infrun.c: 2322
.
.
.
  if (frame_id_eq (frame_unwind_id (get_current_frame ()),
                   step_frame_id))
    {
      /* It's a subroutine call.  */
      CORE_ADDR real_stop_pc;
.
.
.

When there is a subroutine call this if statement fails.  It never
thinks "It's a subroutine call."

Something is horked up in the frame code, but I cannot figure out where.

David Daney.

Re: Unable to step over (n and ni) on mipsel-linux...

[Theodore A. Roth]

On Fri, 20 Aug 2004, David Daney wrote:

> GNU gdb 6.2_2004-08-19-cvs
>
> from the gdb_6_2-branch yesterday.
>
> ../gdbcvs/src/configure  --build=i686-pc-linux --host=mipsel-linux
> --target=mipsel-linux --enable-tui=no
>
> Most of the time when I do next or nexti, gdb is treating it as if I did
> step or stepi.
>
> I have tracked the problem down to this portion of code:
>
> infrun.c: 2322
> .
> .
> .
>   if (frame_id_eq (frame_unwind_id (get_current_frame ()),
>                    step_frame_id))
>     {
>       /* It's a subroutine call.  */
>       CORE_ADDR real_stop_pc;
> .
> .
> .
>
> When there is a subroutine call this if statement fails.  It never
> thinks "It's a subroutine call."
>
> Something is horked up in the frame code, but I cannot figure out where.

I've noticed this problem with the avr port too, but haven't had the
time to look into it. It also appears to have a seeming random element
to it for me: sometimes 'next' will step over the function call, but
most of the time it doesn't.

The problem seems to be independent of which version of gcc I use to
generate the target code. I've noticed the problem with versions of gdb
newer than 6.0.x up through current cvs (my last cvs was
2004-08-05-cvs).

I'm hoping that my problem is related. If there's any testing I can do
with the avr port to help out, please let me know.

---
Ted Roth
PGP Key ID: 0x18F846E9
Jabber ID: troth@jabber.org

Re: Unable to step over (n and ni) on mipsel-linux...

[Andrew Cagney]

> GNU gdb 6.2_2004-08-19-cvs
> 
> from the gdb_6_2-branch yesterday.
> 
> ../gdbcvs/src/configure  --build=i686-pc-linux --host=mipsel-linux
> --target=mipsel-linux --enable-tui=no
> 
> Most of the time when I do next or nexti, gdb is treating it as if I did
> step or stepi.
> 
> I have tracked the problem down to this portion of code:

Sounds like a bug in the MIPS unwind code.  Can you build/test with 
mainline (the fixes won't be backported).

The problem is that, after the step-into the callee, the MIPS unwind 
code is not correctly unwinding back to the caller's frame-ID.  As 
Theodore notes, this is very compiler dependant.

Andrew

> infrun.c: 2322
> .
> .
> .
>   if (frame_id_eq (frame_unwind_id (get_current_frame ()),
>                    step_frame_id))
>     {
>       /* It's a subroutine call.  */
>       CORE_ADDR real_stop_pc;
> .
> .
> .
> 
> When there is a subroutine call this if statement fails.  It never
> thinks "It's a subroutine call."
> 
> Something is horked up in the frame code, but I cannot figure out where.
> 
> David Daney.
> 
> 
> 

Re: Unable to step over (n and ni) on mipsel-linux...

[David Daney]

Andrew Cagney wrote:
>>GNU gdb 6.2_2004-08-19-cvs
>>
>>from the gdb_6_2-branch yesterday.
>>
>>../gdbcvs/src/configure  --build=i686-pc-linux --host=mipsel-linux
>>--target=mipsel-linux --enable-tui=no
>>
>>Most of the time when I do next or nexti, gdb is treating it as if I did
>>step or stepi.
>>
>>I have tracked the problem down to this portion of code:
> 
> 
> Sounds like a bug in the MIPS unwind code.  Can you build/test with 
> mainline (the fixes won't be backported).
> 

I will try the mainline soon.

> The problem is that, after the step-into the callee, the MIPS unwind 
> code is not correctly unwinding back to the caller's frame-ID.  As 
> Theodore notes, this is very compiler dependant.
> 

Currently GDB examines the next instruction to see if it is a branch (or
  jal or jalr..) to see where to place a temporary breakpoint for single
stepping.

Instead of stepping into a function and checking to see if we are in a
different frame (settting a breakpoint at the return address location),
why not set the breakpoint at the return location before making the
function call?


By compiler dependant, do you mean the compiler GDB was built with, or
the one that compiled the target code?


> Andrew
> 
> 

Re: Unable to step over (n and ni) on mipsel-linux...

[Andrew Cagney]

> Andrew Cagney wrote:
> 
>>>>>GNU gdb 6.2_2004-08-19-cvs
>>>>>
>>
>>>>from the gdb_6_2-branch yesterday.
>>
>>>>>
>>>>>../gdbcvs/src/configure  --build=i686-pc-linux --host=mipsel-linux
>>>>>--target=mipsel-linux --enable-tui=no
>>>>>
>>>>>Most of the time when I do next or nexti, gdb is treating it as if I did
>>>>>step or stepi.
>>>>>
>>>>>I have tracked the problem down to this portion of code:
>>
>>> 
>>> 
>>> Sounds like a bug in the MIPS unwind code.  Can you build/test with 
>>> mainline (the fixes won't be backported).
>>> 
> 
> 
> I will try the mainline soon.

Thanks.
> 
>>> The problem is that, after the step-into the callee, the MIPS unwind 
>>> code is not correctly unwinding back to the caller's frame-ID.  As 
>>> Theodore notes, this is very compiler dependant.
>>> 
> 
> 
> Currently GDB examines the next instruction to see if it is a branch (or
>   jal or jalr..) to see where to place a temporary breakpoint for single
> stepping.

> Instead of stepping into a function and checking to see if we are in a
> different frame (settting a breakpoint at the return address location),
> why not set the breakpoint at the return location before making the
> function call?

That would mean examining every instruction to determine if it is a call 
- effectively s/w single step.  GDB tries to do avoid doing that so that 
single-step is faster.

> By compiler dependant, do you mean the compiler GDB was built with, or
> the one that compiled the target code?

For you mipsel-linux-gcc (the one that compiled the target code).

Andrew

> 
> 
>>> Andrew
>>> 
>>> 
> 
> 
> 
> 

Re: Unable to step over (n and ni) on mipsel-linux...

[David Daney]

Andrew Cagney wrote:
>>
>>Currently GDB examines the next instruction to see if it is a branch (or
>>  jal or jalr..) to see where to place a temporary breakpoint for single
>>stepping.
> 
> 
>>Instead of stepping into a function and checking to see if we are in a
>>different frame (settting a breakpoint at the return address location),
>>why not set the breakpoint at the return location before making the
>>function call?
> 
> 
> That would mean examining every instruction to determine if it is a call 
> - effectively s/w single step.  GDB tries to do avoid doing that so that 
> single-step is faster.
> 

For my configuration, for some reason it is already doing this.  Thus my
comment.  If we are doing s/w single step, we would not have to examine
the stack frames.

Could there are some configuration problems?

> 
>>By compiler dependant, do you mean the compiler GDB was built with, or
>>the one that compiled the target code?
> 
> 
> For you mipsel-linux-gcc (the one that compiled the target code).

This implies that if I write assembly language I cannot expect GDB's ni
instruction to work.

I am doing testing with at least three different compiler versions.  GDB
5.3 seems to work well except for crashing when I don't use
-fno-var-tracking.

GDB 6.x seems to be a bit of a down-grade.

David Daney.

Re: Unable to step over (n and ni) on mipsel-linux...

[Daniel Jacobowitz]

On Mon, Aug 23, 2004 at 11:38:39AM -0700, David Daney wrote:
> Andrew Cagney wrote:
> >>
> >>Currently GDB examines the next instruction to see if it is a branch (or
> >>  jal or jalr..) to see where to place a temporary breakpoint for single
> >>stepping.
> > 
> > 
> >>Instead of stepping into a function and checking to see if we are in a
> >>different frame (settting a breakpoint at the return address location),
> >>why not set the breakpoint at the return location before making the
> >>function call?
> > 
> > 
> > That would mean examining every instruction to determine if it is a call 
> > - effectively s/w single step.  GDB tries to do avoid doing that so that 
> > single-step is faster.
> > 
> 
> For my configuration, for some reason it is already doing this.  Thus my
> comment.  If we are doing s/w single step, we would not have to examine
> the stack frames.
> 
> Could there are some configuration problems?

GDB already does this on all MIPS targets.

> This implies that if I write assembly language I cannot expect GDB's ni
> instruction to work.

It should work OK.  You have to have some stack frame anyway, and GDB
has a prologue analyzer.

> I am doing testing with at least three different compiler versions.  GDB
> 5.3 seems to work well except for crashing when I don't use
> -fno-var-tracking.
> 
> GDB 6.x seems to be a bit of a down-grade.

GDB 6.2 and MIPS do not get along very well.  I ran out of time to work
on the MIPS unwinder, but Joel and others have done some work, and I
hope to get back to testing it sometime.

-- 
Daniel Jacobowitz

Re: Unable to step over (n and ni) on mipsel-linux...

[David Daney]

Daniel Jacobowitz wrote:
>>>>Instead of stepping into a function and checking to see if we are in a
>>>>different frame (settting a breakpoint at the return address location),
>>>>why not set the breakpoint at the return location before making the
>>>>function call?
>>>
>>>
>>>That would mean examining every instruction to determine if it is a call 
>>>- effectively s/w single step.  GDB tries to do avoid doing that so that 
>>>single-step is faster.
>>>
>>
>>For my configuration, for some reason it is already doing this.  Thus my
>>comment.  If we are doing s/w single step, we would not have to examine
>>the stack frames.
>>
>>Could there are some configuration problems?
> 
> 
> GDB already does this on all MIPS targets.
> 
> 
>>This implies that if I write assembly language I cannot expect GDB's ni
>>instruction to work.
> 
> 
> It should work OK.  You have to have some stack frame anyway, and GDB
> has a prologue analyzer.
> 

For next and nexti it does not need to analyse the stack frames.

I have half a mind to hack up mips-tdep.c:mips32_next_pc so that it
returns the address following the jal/jalr if step_over_calls ==
STEP_OVER_ALL or some such thing.

David Daney.

Re: Unable to step over (n and ni) on mipsel-linux...

[Daniel Jacobowitz]

On Mon, Aug 23, 2004 at 11:58:07AM -0700, David Daney wrote:
> For next and nexti it does not need to analyse the stack frames.
> 
> I have half a mind to hack up mips-tdep.c:mips32_next_pc so that it
> returns the address following the jal/jalr if step_over_calls ==
> STEP_OVER_ALL or some such thing.

IMO, this is reasonable on targets where we're using software single
step anyway.  It's also reasonable if trust_readonly_sections is true.
Would anyone object to an optional gdbarch method that took a PC, and
returned the return address of the call represented by that PC, if the
instruction is a call?

-- 
Daniel Jacobowitz

Re: Unable to step over (n and ni) on mipsel-linux...

[Andrew Cagney]

> On Mon, Aug 23, 2004 at 11:58:07AM -0700, David Daney wrote:
> 
>>> For next and nexti it does not need to analyse the stack frames.
>>> 
>>> I have half a mind to hack up mips-tdep.c:mips32_next_pc so that it
>>> returns the address following the jal/jalr if step_over_calls ==
>>> STEP_OVER_ALL or some such thing.
> 
> 
> IMO, this is reasonable on targets where we're using software single
> step anyway.  It's also reasonable if trust_readonly_sections is true.
> Would anyone object to an optional gdbarch method that took a PC, and
> returned the return address of the call represented by that PC, if the
> instruction is a call?

Why not add to s/w single-step as a parameter?

Andrew

Re: Unable to step over (n and ni) on mipsel-linux...

[Michael Chastain]

David Daney <ddaney@avtrex.com> wrote:
> By compiler dependant, do you mean the compiler GDB was built with, or
> the one that compiled the target code?

This question comes up a lot -- I think it's underdocumented,
so I'll take a TODO item to write some more documentation on it.

Here's a brain dump.  David, you know half this stuff already,
I'm just collecting it into one place.

===

The version of GDB is important.

The compiler that GDB was built with is important if:

  . gdb fails to build
  . a test in gdb.gdb/*.exp is the issue

If gdb builds successfully, and you're not running one of the tests in
gdb.gdb (which tests the gdb executable itself), then the compiler that
built GDB usually does not influence GDB's behavior at run-time.
GDB is just a big C program.  If a C compiler can compile GDB, it usually
compiles it the way we meant it to.

The target architecture is always important.

The target operating system is always important.

The host architecture and the host operating system are of secondary
importance.  They might be important if the issue involves the remote
protocol and the host operating system is unusually weird.

The compiler that built the target code is critical!  The target
compiler is the program that writes all the debugging information which
GDB reads.  We nearly always need the name and version of the compiler
that built the target code.

Obviously, the debug flags (-g or -ggdb or -gdwarf-2 or -gstabs+)
are critical too.

Usually the target assembler and target linker are not important,
because the target compiler generates the debugging information and
the target assembler and target linker just pass them through.
GDB is sometimes sensitive to the target linker for issues with
shared libraries.

The target's standard C library is important if the problem involves
threads or the problem involves backtracing through the standard library.

Re: Unable to step over (n and ni) on mipsel-linux...

[David Daney]

Michael Chastain wrote:
> David Daney <ddaney@avtrex.com> wrote:
> 
>>By compiler dependant, do you mean the compiler GDB was built with, or
>>the one that compiled the target code?
> 
> 
> This question comes up a lot -- I think it's underdocumented,
> so I'll take a TODO item to write some more documentation on it.
> 
> Here's a brain dump.  David, you know half this stuff already,
> I'm just collecting it into one place.
> 
> ===
> 
> The version of GDB is important.
> 
> The compiler that GDB was built with is important if:
> 
>   . gdb fails to build
>   . a test in gdb.gdb/*.exp is the issue
> 
> If gdb builds successfully, and you're not running one of the tests in
> gdb.gdb (which tests the gdb executable itself), then the compiler that
> built GDB usually does not influence GDB's behavior at run-time.
> GDB is just a big C program.  If a C compiler can compile GDB, it usually
> compiles it the way we meant it to.
> 
> The target architecture is always important.
> 
> The target operating system is always important.
> 
> The host architecture and the host operating system are of secondary
> importance.  They might be important if the issue involves the remote
> protocol and the host operating system is unusually weird.
> 
> The compiler that built the target code is critical!  The target
> compiler is the program that writes all the debugging information which
> GDB reads.  We nearly always need the name and version of the compiler
> that built the target code.
> 
> Obviously, the debug flags (-g or -ggdb or -gdwarf-2 or -gstabs+)
> are critical too.
> 
> Usually the target assembler and target linker are not important,
> because the target compiler generates the debugging information and
> the target assembler and target linker just pass them through.
> GDB is sometimes sensitive to the target linker for issues with
> shared libraries.
> 
> The target's standard C library is important if the problem involves
> threads or the problem involves backtracing through the standard library.

I don't deny that all of this is true.

I just have a philosophical problem with the following very specific case:

mipsel-linux with glibc2.2.5/linuxthreads.

I export LD_BIND_NOW=1 so there are no dynamic library stub problems.

If I do 'ni' when pc is positioned on a jal or jalr instruction GDB
should not have to examine debugging information generated by the
compiler.  It should place a temporary breakpoint after the instruction
and continue.

David Daney.