Re: Binutils 2.29.1 breaks libpcap on sparc32 by filling .got

[Alan Modra <amodra at gmail dot com>]

On Thu, Dec 07, 2017 at 02:58:30PM +0100, Rolf Eike Beer wrote:
> I have a T5120 running Gentoo Linux (64 bit kernel, 32 bit userspace). When 
> switching between binutils 2.28.1 and 2.29.1 I can break/unbreak libpcap. The 
> broken version can easily be detected: tcpdump crashes on start. When I 
> compare the 2 libraries using diffoscope this is the diff (truncated):
> 
> --- libpcap-good
> +++ libpcap-bad
> ├── readelf --wide --decompress --hex-dump=.got {}
> │ @@ -1,161 +1,161 @@
> │  
> │  Hex dump of section '.got':
> │ -  0x0004a000 00049f18 00000000 00000000 00000000 ................
> │ -  0x0004a010 00000000 00000000 00000000 00000000 ................
> │ -  0x0004a020 00000000 00000000 00000000 00000000 ................
> │ -  0x0004a030 00000000 00000000 00000000 00000000 ................
> │ -  0x0004a040 00000000 00000000 00000000 00000000 ................
> │ +  0x0004a000 00049f18 000054c0 000054e0 00005500 ......T...T...U.
> │ +  0x0004a010 00005520 000058e0 00005b00 000270a0 ..U ..X...[...p.
> │ +  0x0004a020 0004afa4 00006860 00006880 000069a0 ......h`..h...i.
> │ +  0x0004a030 00006ca0 00006fc0 00007180 00007300 ..l...o...q...s.
> │ +  0x0004a040 000075a0 000076c0 000080a0 000270b0 ..u...v.......p.
> 
> This section is the only difference.  I have tried adding 
> 0fb7012e88683b8bd67a4fb8f782359fa0e11724, 
> 00956d3a8ab1b56fcdf63aee4ed5c5a1d46a7a48, and 
> f6a36b0c9e537e4525f3b0687a4f76b4f77bf173 to the build, or reverting 
> 5b86074c4a84e32ca55a6c72c5fca45d97dc9374, neither made a difference. The 
> results above are done including the Gentoo patchset, but I verified that the 
> vanilla version breaks the same way, it just has more changes.
> 
> I have build many other things with these binutils and have not observed a 
> breakage elsewhere, but this one is very stable and can be reproduced every 
> time.
> 
> Any hints?

sparc and sparc64 glibc ld.so is broken in its handling of RELATIVE
relocations.

auto inline void
__attribute__ ((always_inline))
elf_machine_rela_relative (Elf32_Addr l_addr, const Elf32_Rela *reloc,
			   void *const reloc_addr_arg)
{
  Elf32_Addr *const reloc_addr = reloc_addr_arg;
  *reloc_addr += l_addr + reloc->r_addend;
}

That's wrong.  The original section contents should generally be
ignored for a RELA target.  (In contrast to a REL target where the
section contents are the addend.)  Code in elf_machine_rela handling
R_SPARC_RELATIVE also wrongly adds to the section contents.

So it looks like sparc and sparc64 ld needs to be sure to zero section
contents whenever a RELATIVE relocation is emitted, to avoid this
glibc bug.

-- 
Alan Modra
Australia Development Lab, IBM