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

[David Daney <ddaney@avtrex.com>]

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.