Re: PPC relocs in shared libraries

[Daniel Jacobowitz <drow at mvista dot com>]

On Wed, Sep 25, 2002 at 04:09:34PM -0700, Geoff Keating wrote:
> > Date: Wed, 25 Sep 2002 18:02:09 -0400
> > From: Daniel Jacobowitz <drow@mvista.com>
> 
> > H. J.'s binutils releases have had this patch to elf32-ppc.c applied for
> > some time now:
> > 
> > 2001-10-07  Jakub Jelinek  <jakub@redhat.com>
> > 
> >         * elf32-ppc.c (ppc_elf_check_relocs): Don't output relocations
> >         for debugging sections.
> >         (ppc_elf_relocate_section): Likewise.
> > 
> > diff -ur binutils-2.13.90.0.4/binutils-2.13.90.0.4/bfd/elf32-ppc.c branch-src/bfd/elf32-ppc.c
> > --- binutils-2.13.90.0.4/binutils-2.13.90.0.4/bfd/elf32-ppc.c   2002-08-14 13:35:11.000000000 -0400
> > +++ branch-src/bfd/elf32-ppc.c  2002-09-25 17:39:20.000000000 -0400
> > @@ -2420,7 +2420,7 @@
> >           /* fall through */
> >  
> >         default:
> > -         if (info->shared && (sec->flags & SEC_ALLOC) != 0)
> > +         if (info->shared)
> >             {
> >  #ifdef DEBUG
> >               fprintf (stderr, "ppc_elf_check_relocs need to create relocation for %s\n",
> > @@ -3178,8 +3178,7 @@
> >         case (int) R_PPC_ADDR14:
> >         case (int) R_PPC_UADDR32:
> >         case (int) R_PPC_UADDR16:
> > -         if (info->shared && r_symndx != 0
> > -             && (input_section->flags & SEC_ALLOC) != 0)
> > +         if (info->shared && r_symndx != 0)
> >             {
> >               Elf_Internal_Rela outrel;
> >               int skip;
> > 
> > 
> > Geoff rejected the patch, saying it was the debugger's job to handle these
> > relocations.  I'm not sure if that's right - I don't see the point in having
> > to handle them for shared libraries - but GDB needs the code to do so in
> > order to debug unlinked modules.  So, as far as that goes, we're all
> > together.  But in readelf we have this bit (around line 7990):
> > 
> >           for (rp = rela; rp < rela + nrelas; ++rp)
> >             { 
> >               if (rp->r_offset
> >                   != (bfd_vma) ((unsigned char *) &external->cu_abbrev_offset
> >                                 - section_begin))
> >                 continue;
> > 
> >               if (is_32bit_elf)
> >                 { 
> >                   sym = symtab + ELF32_R_SYM (rp->r_info);
> > 
> >                   if (ELF32_ST_TYPE (sym->st_info) != STT_SECTION)
> >                     { 
> >                       warn (_("Skipping unexpected symbol type %u\n"),
> >                             ELF32_ST_TYPE (sym->st_info));
> >                       continue;
> >                     }
> > 
> > Well, in a shared library these have all been resolved to *ABS* relocs, and
> > the warning triggers.  Should the warning be corrected, or the relocations
> > removed?
> 
> The warning should be corrected.  I think this code will do the right
> thing if the warning is suppressed for this case.

All right, I'm confused.  I'll come back and spend some more time on
this later but for now I'm seeking opinions - is the code in readelf
right, anyway?

First:
          if (relsec->sh_type != SHT_RELA
              || SECTION_HEADER (relsec->sh_info) != section)
            continue;

So we're looking at RELA sections.  RELA does not use the in-section
data, does it?  But readelf goes on to do:

              compunit.cu_abbrev_offset += rp->r_addend;

Which then will apply the value twice, or to garbage, depending on what
version of binutils you happen to be using.  So I fixed that in my
local copy.

Then there are dozens of other places in readelf which do not apply
relocations.  GDB doesn't do it either unless you have a patch I
haven't finished cleaning up yet (first posted four or five months ago,
and I got busy elsewhere).  So I get things like this:

-     DW_AT_stmt_list   : 0     
-     DW_AT_high_pc     : 0x24 36       
-     DW_AT_low_pc      : 0 0   
+     DW_AT_stmt_list   : 142   
+     DW_AT_high_pc     : 0x1a04 6660   
+     DW_AT_low_pc      : 0x19e0 6624   

-  Extended opcode 2: set Address to 0x0
+  Extended opcode 2: set Address to 0x182c

These two have the same relocations; one happens to write the relocated
values into the section and the other doesn't.


So: Do we require full relocation processing on debug sections?  If so,
I'm going to need to finish up the patch to provide an easy way for a
client like readelf to relocate a section reliably.  At present we
don't implement this relocation except for the location of the abbrev
table.

Also, should this code be supporting REL relocations?  Or do the
DWARF-2 sections always have RELA for some reason?
 

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer