duplicated source file names

duplicated source file names

[John Williams]

Hi,

Debugging a linux kernel, there are many instances where source files of 
the same name but different in directories exist - for example super.c 
appears in several of the filesystem subdirectories.

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 all on gdb5.0 under RH linux (but also same under Cygwin).

Is this a known issue?  IS there a way I can qualify the function name 
(or indeed source file) to specify *which* super.c it should find a 
function in?

Thanks,

John

Re: duplicated source file names

[Keith Seitz]

On Thu, 2003-08-14 at 00:08, John Williams 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?
- "info func ext2_read_super": Right info?
- "tk gdbtk_loc ext_read_super": Right info?

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.

Keith

Re: duplicated source file names

[John Williams]

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
> 


-- 
Dr John Williams, Research Fellow,
Reconfigurable Computing, School of ITEE
University of Queensland, Brisbane, Australia
Ph : (07) 3365 8305

Re: duplicated source file names

[Keith Seitz]

On Thu, 2003-08-14 at 15:01, John Williams wrote:
> > - "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?

Close. Binutils doesn't really read debug info the way gdb does. They
both try to do the same thing, but gdb looks at it slightly differently.

> > - "tk gdbtk_loc ext_read_super": Right info?
>
> I get - Error: invalid command name "gdbtk_loc"

Oops. Should have been "gdb_loc" not "gdbtk_loc".

> 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.

Ah. Understood.

> 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.
> 

Yeah -- that's been the sad approach used by most. As I recall we have a
file in gdb that used to use the same filename as another file in bfd.
Instead fixing gdb, someone renamed gdb's file!

Keith

Re: duplicated source file names

[John Williams]

Keith Seitz wrote:
> On Thu, 2003-08-14 at 15:01, John Williams wrote:
> 
>>>- "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?
> 
> 
> Close. Binutils doesn't really read debug info the way gdb does. They
> both try to do the same thing, but gdb looks at it slightly differently.

OK.
>>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.
> 
> Yeah -- that's been the sad approach used by most. As I recall we have a
> file in gdb that used to use the same filename as another file in bfd.
> Instead fixing gdb, someone renamed gdb's file!

ha!  well if it's good enough for gdb, it's good enough for me :)

I have the source of this cross-gdb and can build it myself, if I feel 
inspired one day I might look into it.  Recommend any resources (old 
mailing list archives perhaps?) where I might find info on how the bug 
was fixed?

Thanks,

John

Re: duplicated source file names

[Keith Seitz]

On Thu, 2003-08-14 at 16:44, John Williams wrote:

> I have the source of this cross-gdb and can build it myself, if I feel 
> inspired one day I might look into it.  Recommend any resources (old 
> mailing list archives perhaps?) where I might find info on how the bug 
> was fixed?

I don't think it's ever been fixed. If it has, it's because of a massive
amount of work going on in the symbol readers and symbol table. You'd
not likely back-patch 5.0 (or event 5.3) with it.

I encourage you to file a bug on it. Heck, make their day: file a bug
and submit a dejagnu testcase for it! This way, there's one more failure
to track.

Keith

Re: duplicated source file names

[Andrew Cagney]

"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

Re: duplicated source file names

[Tom Tromey]

>>>>> "Andrew" == Andrew Cagney <ac131313@redhat.com> writes:

Andrew> With out any other evidence, I'd assume this is fixed in a more recent
Andrew> set of developer tools (debugger, binutils, compiler, ...).  Perhaps
Andrew> look in GDB's bug database - http://www.gnu.org/software/gdb/bugs/.

There was a discussion of this problem on the gdb list sometime last
year (or maybe earlier).  As I recall we ended up with a patch where,
if you specify the full path to a file, gdb will normalize it
internally and not be confused.

I don't know how this applies to insight, exactly.  I suppose from the
console you can type the name unambiguously.  And I doubt this change
is in 5.0.

Tom

RE: duplicated source file names

[Steve Morgan]

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