From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14134 invoked by alias); 10 Dec 2003 17:17:17 -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 14126 invoked from network); 10 Dec 2003 17:17:16 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 10 Dec 2003 17:17:16 -0000 Received: from drow by nevyn.them.org with local (Exim 4.24 #1 (Debian)) id 1AU7xb-0001mT-R3 for ; Wed, 10 Dec 2003 12:17:15 -0500 Date: Wed, 10 Dec 2003 17:17:00 -0000 From: Daniel Jacobowitz To: gdb@sources.redhat.com Subject: Re: optind Message-ID: <20031210171715.GA6721@nevyn.them.org> Mail-Followup-To: gdb@sources.redhat.com References: <20031210142045.GL23712@ata.cs.hacettepe.edu.tr> <20031210144917.GA9115@nevyn.them.org> <20031210160910.GM23712@ata.cs.hacettepe.edu.tr> <20031210165318.GO23712@ata.cs.hacettepe.edu.tr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i X-SW-Source: 2003-12/txt/msg00167.txt.bz2 On Wed, Dec 10, 2003 at 12:04:22PM -0500, Ian Lance Taylor wrote: > Baurjan Ismagulov writes: > > > On Wed, Dec 10, 2003 at 05:12:56PM +0100, Andreas Schwab wrote: > > > It also exists in the executable, due to a COPY relocation. > > > > Thanks much, I see it now! > > > > And how should gdb know which one to use? > > gdb should always use the one in the executable. That is the one the > code in the shared library will also be using, because that is the > address will be in the GOT. > > In principle, while debugging shared library code, gdb could observe > that there is a GOT relocation for optind, and look at the GOT table > in memory to decide which address to use. > > Alternatively, gdb could guess that if there is a global variable in > the executable, that any reference to that global variable in the > shared library will refer to the one in the executable. This will > normally be true, but will fail in cases where the library is > controlling visibility in any of various different ways. For global variables the sensible default is to use the one in the executable. This gets much more fun, of course, for function addresses. > In practice I have no idea what gdb actually does. Neither does GDB. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer