This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Unable to step over (n and ni) on mipsel-linux...
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.