DSO with relocations and GDB.

The powerpc eabi DSO (dynamic shared object) I'm debugging
using GDB
6.6  has .debug_info and other debug tables which have
unresolved
relocations. The .rela_debug_info is available in the DSO
and it has
sh_link set to .symtab, sh_info to .debug_info.  However,
the bfd code
in GDB 6.6 does not seem to associate the .debug_info with
corresponding .rela_debug.info section. When GDB attempts to
relocate
these debug tables,  bfd does not recognize that the section
has
relocations. This results in zero value for the offset for a
symbol
from debug table and gets wrong address for a symbol
lookup.
Any suggestions for solution to this problem? Is there a bfd
function
which can be called from GDB to associate debug tables and
their
relocation section counter parts?
Thanks

On Fri, Apr 18, 2008 at 03:50:00PM -0700, Ananth Sowda
wrote:
> The powerpc eabi DSO (dynamic shared object) I'm
debugging using GDB
> 6.6  has .debug_info and other debug tables which have
unresolved
> relocations. The .rela_debug_info is available in the
DSO and it has
> sh_link set to .symtab, sh_info to .debug_info. 
However, the bfd code
> in GDB 6.6 does not seem to associate the .debug_info
with
> corresponding .rela_debug.info section. When GDB
attempts to relocate
> these debug tables,  bfd does not recognize that the
section has
> relocations.

What does objdump -h say about this file?  IOW, what do you
mean by
"does not seem to associate"?

GDB is supposed to handle this case correctly.  However,
we've also
pretty well established that the linker is wrong to emit
such
relocations; if you have the option of using a different
linker
version which does not do so, I recommend it.

-- 
Daniel Jacobowitz
CodeSourcery

On 4/18/08, Daniel Jacobowitz <drowfalse.org> wrote:
> On Fri, Apr 18, 2008 at 03:50:00PM -0700, Ananth Sowda
wrote:
> > The powerpc eabi DSO (dynamic shared object) I'm
debugging using GDB
> > 6.6  has .debug_info and other debug tables which
have unresolved
> > relocations. The .rela_debug_info is available in
the DSO and it has
> > sh_link set to .symtab, sh_info to .debug_info. 
However, the bfd code
> > in GDB 6.6 does not seem to associate the
.debug_info with
> > corresponding .rela_debug.info section. When GDB
attempts to relocate
> > these debug tables,  bfd does not recognize that
the section has
> > relocations.
>
> What does objdump -h say about this file?  IOW, what do
you mean by
> "does not seem to associate"?

BFD internal section data structure for .debug_info section
is not
marked with SEC_RELOC in flags and number of relocation
records for
the section is 0.  objdump -h output shows that
sh_link(points to
.symtab) and sh_link(points to .debug_info) are set
correctly for the
.rela_debug.info section.

>
> GDB is supposed to handle this case correctly. 
However, we've also
> pretty well established that the linker is wrong to
emit such
> relocations; if you have the option of using a
different linker
> version which does not do so, I recommend it.

I agree using a linker which resolves the relocations fixes
the problem.
-Thanks

On Mon, Apr 21, 2008 at 11:26:03AM -0700, Ananth Sowda
wrote:
> On 4/18/08, Daniel Jacobowitz <drowfalse.org> wrote:
> > On Fri, Apr 18, 2008 at 03:50:00PM -0700, Ananth
Sowda wrote:
> > > The powerpc eabi DSO (dynamic shared object)
I'm debugging using GDB
> > > 6.6  has .debug_info and other debug tables
which have unresolved
> > > relocations. The .rela_debug_info is
available in the DSO and it has
> > > sh_link set to .symtab, sh_info to
.debug_info.  However, the bfd code
> > > in GDB 6.6 does not seem to associate the
.debug_info with
> > > corresponding .rela_debug.info section. When
GDB attempts to relocate
> > > these debug tables,  bfd does not recognize
that the section has
> > > relocations.
> >
> > What does objdump -h say about this file?  IOW,
what do you mean by
> > "does not seem to associate"?
> 
> BFD internal section data structure for .debug_info
section is not
> marked with SEC_RELOC in flags and number of relocation
records for
> the section is 0.  objdump -h output shows that
sh_link(points to
> .symtab) and sh_link(points to .debug_info) are set
correctly for the
> .rela_debug.info section.

That's the real problem; you may want to ask the binutils
list
or debug how with sh_link/sh_info set there is still no
SEC_RELOC
flag.

-- 
Daniel Jacobowitz
CodeSourcery

> > BFD internal section data structure for
.debug_info section is not
> > marked with SEC_RELOC in flags and number of
relocation records for
> > the section is 0.  objdump -h output shows that
sh_link(points to
> > .symtab) and sh_link(points to .debug_info) are
set correctly for the
> > .rela_debug.info section.
>
> That's the real problem; you may want to ask the
binutils list
> or debug how with sh_link/sh_info set there is still no
SEC_RELOC
> flag.
>
> --
> Daniel Jacobowitz
> CodeSourcery
>
Thanks for your suggestion.  One correction and further
observation follows:
 sh_info points to .debug_info  and sh_link is pointing to
.dynsym,
not .symtab. This is expected outcome in a ET_DYN file.

However, the bfd/elf.c code shown below does not handle
relocations
using .dynsym.

/* If this reloc section does not use the main symbol table
we
           don't treat it as a reloc section.  BFD can't
adequately
           represent such a section, so at least for now, we
don't
           try.  We just present it as a normal section.  We
also
           can't use it as a reloc section if it points to
the null
           section, an invalid section, or another reloc
section.  */
        if (hdr->sh_link != elf_onesymtab (abfd)
            || hdr->sh_info == SHN_UNDEF
            || (hdr->sh_info >= SHN_LORESERVE
&& hdr->sh_info <= SHN_HIRESERVE)
            || hdr->sh_info >= num_sec
            || elf_elfsections
(abfd)[hdr->sh_info]->sh_type == SHT_REL
            || elf_elfsections
(abfd)[hdr->sh_info]->sh_type == SHT_RELA)
          return _bfd_elf_make_section_from_shdr (abfd, hdr,
name,
                                                  shindex);

On Mon, Apr 21, 2008 at 04:26:15PM -0700, Ananth Sowda
wrote:
> Thanks for your suggestion.  One correction and further
observation follows:
>  sh_info points to .debug_info  and sh_link is pointing
to .dynsym,
> not .symtab. This is expected outcome in a ET_DYN
file.

I see.  Well, you can raise this on the binutils list, but
I'm not
sure what there is to do about it.  Non-ALLOC sections
referencing
.dynsym is a little peculiar.

-- 
Daniel Jacobowitz
CodeSourcery