Symbols in same range

Symbols in same range

[Fabian Cenedese]

Hi

Is it correct to have several symbols in the same symtab range? Like:

maintenance_print_psymbols:
...
Partial symtab for source file N:/Indel-PPC/Tests/gccext3/OS/Inos/Src/Inos_mod.cpp (object 0x95bbb0)
Symbols cover text addresses 0x728e0-0xa89e0

Partial symtab for source file N:/Indel-PPC/Tests/gccext3/OS/Inos/Src/Inos_1ms.cpp (object 0x95b148)
Symbols cover text addresses 0x1918-0xa74dc

Partial symtab for source file N:/Indel-PPC/Tests/gccext3/OS/Inos/Src/Inos.cpp (object 0x9cc548)
Symbols cover text addresses 0x1918-0xa7168

Partial symtab for source file N:/Indel-PPC/Tests/gccext3/OS/Inos/Src/Inos_lib.cpp (object 0x95bb00)
Symbols cover text addresses 0x71afc-0xa799c
...

I think that this is one problem I have for not getting the right line info
for a PC. I tried to comment an example here:

map file:
 .startup       0x00098a58      0xf7c N:/Indel-PPC/Tests/gccext3/lib41/libinos.603(Inos.603)
                0x00099890                _INI_0200_INOS()
                0x00099960                inos_main

Find line to pc=0x99928 with find_pc_line:
find_pc_line, pc=0x99928
	find_pc_sect_line, pc=0x99928
		lookup_minimal_symbol_by_pc, pc=0x99928
		-> msymbol="_INI_0200_INOS"
		find_pc_sect_symtab, pc=0x99928
			lookup_minimal_symbol_by_pc_section, pc=0x99928
			-> msymbol="_INI_0200_INOS"
			s='Inos_mod.cpp'
			find_pc_sect_psymtab, pc=0x99928
				lookup_minimal_symbol_by_pc_section
				-> msymbol="_INI_0200_INOS"
				tpst='Inos_mod.cpp'
				find_pc_sect_psymbol
				-> p="CEnd"
			-> ps='Inos_mod.cpp'
		-> s='Inos_mod.cpp'
		best_symtab=NULL
	-> .line=0

The found msymbol is always correct, but when gdb continues to find
the corresponding block it takes the symtab from a wrong file. But the
addresses in there don't match (only the range) and the returned
result is .line=0.

The problem may come because of various code sections. We have
code not only in .text but also in different sections like .startup or
.cache (for better memory handling on the target). Various source
files place code in the different sections which of course get placed
together. So it is somehow correct that a source file symtab has
a very big range if you only look at the lowest and highest used
address. But not the whole range is covered and of course the
ranges will almost all overlap.

Is this an error in the finding strategy of gdb, like, it should look
in all symtabs and not only in the first whose range matches?
Or is there a possibility to find the block from the msymbol
which is found correctly? Something else I can do to improve
my results?

Thanks

bye  Fabi

Re: Symbols in same range

[Daniel Jacobowitz]

On Wed, Dec 13, 2006 at 09:44:47AM +0100, Fabian Cenedese wrote:
> Hi
> 
> Is it correct to have several symbols in the same symtab range? Like:

Yes, this is not uncommon.  For instance, if one source file defines
linkonce routines or functions in multiple sections.

I have worked on several problems related to this one lately.  Are you
using GDB HEAD?  If not, does it do any better?  Does the patch in this
message help?
  http://sourceware.org/ml/gdb-patches/2006-12/msg00005.html

> 			find_pc_sect_psymtab, pc=0x99928
> 				lookup_minimal_symbol_by_pc_section
> 				-> msymbol="_INI_0200_INOS"
> 				tpst='Inos_mod.cpp'
> 				find_pc_sect_psymbol
> 				-> p="CEnd"
> 			-> ps='Inos_mod.cpp'
> 		-> s='Inos_mod.cpp'
> 		best_symtab=NULL
> 	-> .line=0
> 
> The found msymbol is always correct, but when gdb continues to find
> the corresponding block it takes the symtab from a wrong file. But the
> addresses in there don't match (only the range) and the returned
> result is .line=0.

There should be a psymbol in the correct psymtab which is closer to the
specified pc.  What symbols are at or directly before that location?

> Is this an error in the finding strategy of gdb, like, it should look
> in all symtabs and not only in the first whose range matches?

It should find the correct psymtab.  You'll see that
find_pc_sect_psymtab actually loops over them all.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Symbols in same range

[Fabian Cenedese]

At 13:13 13.12.2006 -0500, Daniel Jacobowitz wrote:
>On Wed, Dec 13, 2006 at 09:44:47AM +0100, Fabian Cenedese wrote:
>> Is it correct to have several symbols in the same symtab range? Like:
>
>Yes, this is not uncommon.  For instance, if one source file defines
>linkonce routines or functions in multiple sections.
>
>I have worked on several problems related to this one lately.  Are you
>using GDB HEAD?  If not, does it do any better?  Does the patch in this
>message help?
>  http://sourceware.org/ml/gdb-patches/2006-12/msg00005.html

Unfortunately not. But then again I'm on 6.5 so there may be other
changes related to it. I can't change to HEAD right now but maybe
some time later.

"This is a loop over all psymtabs and a fearsome lot of symbol lookups;"

Yeah, I sometimes thought so as well :)

>> The found msymbol is always correct, but when gdb continues to find
>> the corresponding block it takes the symtab from a wrong file. But the
>> addresses in there don't match (only the range) and the returned
>> result is .line=0.
>
>There should be a psymbol in the correct psymtab which is closer to the
>specified pc.  What symbols are at or directly before that location?
>
>> Is this an error in the finding strategy of gdb, like, it should look
>> in all symtabs and not only in the first whose range matches?
>
>It should find the correct psymtab.  You'll see that
>find_pc_sect_psymtab actually loops over them all.

I'm sure now that the algorithm is working fine. The main problem
is that there are no matching psymtabs.

find_pc_sect_psymtab (CORE_ADDR pc, asection *section)
...
  ALL_PSYMTABS (objfile, pst)
  {
    if (pc >= pst->textlow && pc < pst->texthigh)

The biggest pst->texthigh is the one from the last symbol in the
.text section. For some reason there are no psymbols for the
other code sections. So my problem lies probably more in the
reading and creating of those symbols, or even in gcc's debug
info.
When I put the other code in the .text section as well it works
fine.

Thanks

bye  Fabi