From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23941 invoked by alias); 23 Aug 2004 19:19:05 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 23932 invoked from network); 23 Aug 2004 19:19:04 -0000 Received: from unknown (HELO avtrex.com) (216.102.217.178) by sourceware.org with SMTP; 23 Aug 2004 19:19:04 -0000 Received: from avtrex.com ([192.168.0.111] RDNS failed) by avtrex.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 23 Aug 2004 12:15:32 -0700 Message-ID: <412A4255.9070900@avtrex.com> Date: Mon, 23 Aug 2004 19:19:00 -0000 From: David Daney User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031030 MIME-Version: 1.0 To: Michael Chastain CC: eliz@gnu.org, cagney@gnu.org, gdb@sources.redhat.com Subject: Re: Unable to step over (n and ni) on mipsel-linux... References: <412649F4.9040002@avtrex.com> <412A25B1.7080308@gnu.org> <412A30E5.9080809@avtrex.com> <412A3FF4.nailCRF28XFLA@mindspring.com> In-Reply-To: <412A3FF4.nailCRF28XFLA@mindspring.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Aug 2004 19:15:33.0157 (UTC) FILETIME=[8FCD6D50:01C48945] X-SW-Source: 2004-08/txt/msg00292.txt.bz2 Michael Chastain wrote: > David Daney 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.