[PATCH] Fix Alpha with gcc 3.1

[Daniel Jacobowitz]

On Mon, Dec 17, 2001 at 05:29:12PM +0100, Jakub Jelinek wrote:
> Hi!
> 
> With quite recent gcc and binutils, it is often not possible to build C++
> binaries on Alpha due to errors like
> termios.o(.eh_frame+0x538): relocation truncated to fit: SREL32 gnu.linkonce.t._ZNSo5flushEv
> termios.o(.eh_frame+0x558): relocation truncated to fit: SREL32 gnu.linkonce.t._ZNKSt9basic_iosIcSt11char_traitsIcEE5widenEc
> (doesn't matter here whether --eh-frame-hdr patch is in or not).
> The reason is that eelf64_alpha_relocate_section tries to relocate a SREL32
> against either r_symndx 0 (without --eh-frame-hdr patch) or STT_SECTION
> symbol of discarded section.
> This patch has 2 parts, one is a cleanup + bug fix
> (elf_reloc_symbol_deleted_p was not taking into account SHF_MERGE sections),

Just checking - is it possible for SHF_MERGE sections to actually be
discarded?  More specifically, if:
  elf_section_data (sec)->sec_info_type == ELF_INFO_TYPE_MERGE
does that mean that we are keeping and actually merging this section
into an output section?

There should be tests for all of this, but I couldn't figure out how to
add them at the time.

> the other is actual Alpha patch.
> There I'm not exactly sure what should be done.
> In .eh_frame case, --eh-frame-hdr patch ensures what exactly is written into
> memory during _bfd_final_link_relocate doesn't matter as the memory is not
> output anyway.
> The options include:
> 1) the elf64-alpha.c hunk below
> 2) similarly, just with elf_section_ignore_discarded_relocs function
>    exported out of elflink.h and add it to the test in elf64-alpha.c
> 3) add new special return value for _bfd_elf_section_offset
>    ((bfd_vma) -2) and assign them meaning:
>    -1: skip dynamic reloc if any, the memory against which the reloc
>    won't be in the final object
>    -2: skip dynamic reloc only, reloc must be done (without overflow)
>    -2 would be returned just for the make_relative/make_lsda_relative
>    optimizations ATM.
>    If -1 was returned, _bfd_final_link_relocate could be skipped in the
>    targets and in case of relocs for which no dynamic reloc is created,
>    _bfd_elf_section_offset could be called when overflow happened
>    and just see if it was (bfd_vma) -1, in which case just pretend
>    no overflow
> 4) in elflink.h, move the elf_section_ignore_discarded_relocs
>    test just around the actual warnings and clear relocs always.
>    In addition to this, elf64-alpha.c either would need to skip
>    _bfd_final_link_relocate if r_symndx == 0 (is this safe?) or
>    just kill the overflow warning if r_symndx == 0.

What really should happen is that at the exact same time we optimize
whichever sections, we should fix up their relocations also.  It's not
clear to me that we have the infrastructure to do this right now,
because the relocations will be re-read from the input file later.  If
you want to see why this should happen, take the following testcase:

int bar()
{
  return 2;
}

int foo() __attribute__((__section__(".text.foo")));
int foo()
{
  return 1;
}

int main()
{
  return 3;
}


Compile with debugging.  Link it with a linker script which discards
.text.foo, and --emit-relocs.

RELOCATION RECORDS FOR [.stab]:
OFFSET   TYPE              VALUE 
00000014 R_386_32          .text
00000020 R_386_32          .text
0000011c R_386_32          bar
00000158 R_386_32          foo
00000194 R_386_32          main
000001d0 R_386_32          .text

See the relocation to foo?  That shouldn't be there.  Worse, the
offsets are against the original stab section.  My patch didn't break
this, just aggravated it; even the BINCL optimizations would mess up
--emit-relocs.  We're now using this technique in enough places that
someone more courageous than I really should fix it.


Thanks for introducing the discard section macro, by the way.  That
code was duplicated in too many places.  It wouldn't surprise me if we
found a few more.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer