From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18293 invoked by alias); 18 Aug 2003 16:03:17 -0000 Mailing-List: contact insight-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: insight-owner@sources.redhat.com Received: (qmail 18281 invoked from network); 18 Aug 2003 16:03:16 -0000 Received: from unknown (HELO pintail.mail.pas.earthlink.net) (207.217.120.122) by sources.redhat.com with SMTP; 18 Aug 2003 16:03:16 -0000 Received: from user-119aqf6.biz.mindspring.com ([66.149.105.230] helo=RhodeIsland) by pintail.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19omTP-0007DF-00; Mon, 18 Aug 2003 09:03:12 -0700 From: "Steve Morgan" To: "'Andrew Cagney'" , Cc: Subject: RE: duplicated source file names Date: Mon, 18 Aug 2003 16:03:00 -0000 Message-ID: <000401c365a2$37b37140$6401a8c0@telenix.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <3F3CFD6D.8030007@redhat.com> X-SW-Source: 2003-q3/txt/msg00105.txt.bz2 I have the same situation in 5.3. I have found the function browser (Ctrl+F) useful for setting breakpoints in this case. It lists all functions across identically named files. Steve -----Original Message----- From: Andrew Cagney [mailto:ac131313@redhat.com] Sent: Friday, August 15, 2003 11:34 AM To: jwilliams@itee.uq.edu.au Cc: insight@sources.redhat.com Subject: Re: duplicated source file names "It should work". With out any other evidence, I'd assume this is fixed in a more recent set of developer tools (debugger, binutils, compiler, ...). Perhaps look in GDB's bug database - http://www.gnu.org/software/gdb/bugs/. BTW, the current reason for GDB having uniquely named files is for consistency and to avoid the build problems with: cc -c a/foo.c cc -c b/foo.c enjoy, Andrew > Hi Keith, > > Keith Seitz wrote: > > However, when debugging this in insight, it only seems to be able to "recognise" one instance of a particular filename. So, even though I type in the name of a function in the function drop down "ext2_read_super", which exists in fs/ext2/super.c, Insight displays the file /fs/super.c. > > This is a pretty well-known issue for me... I still have nightmares > about it. The problem is not really insight, as I recall. Here's how to > check: > > Try a couple of things. Open a console window and enter the commands: > > - "list ext2_read_super": Does it return the correct source? > > Nope - it lists the "correct" line numbers from the wrong file. I'm guessing this is a problem in the binutils addr2line, is that what it's for? > > - "info func ext2_read_super": Right info? > > It says "super.c", then gives the corrent function declaration. > > - "tk gdbtk_loc ext_read_super": Right info? > > I get - Error: invalid command name "gdbtk_loc" > > Send results to the list. I'm pretty sure that gdb is failing on this, > but it has been a while, and maybe they fixed it and Insight is behind > the times. > > BTW, gdb/insight 5.0 is WAY old... Even if it is a gdb problem, I doubt > you're going to get much help with a release that several years old. > > Yeah I realise that - this is a cross-debugger for an embedded system, short of forward-porting it myself (*not* gonna happen!) I don't really have a lot of options. > > I'm not too stressed about this, I can just rename the source file and rebuild the project as I need to, just wanted to know if there was something simple I might do. > > Thanks, > > John > > > Keith