R_MIPS_GOT16 bug

R_MIPS_GOT16 bug

[Ralf Baechle]

Hi Mark,

Here is a test case for R_MIPS_GOT16 problem.  Let's take a look at the
disassembler output:

nuke:     file format elf32-bigmips

Disassembly of section .text:

00000000004000b0 <_ftext>:
	...

00000000004000d0 <hurz>:
  4000d0:	3c1c0fc0 	lui	$gp,0xfc0
  4000d4:	279c7f20 	addiu	$gp,$gp,32544
  4000d8:	0399e021 	addu	$gp,$gp,$t9

 -> will point to 0x10007ff0 == gp

  4000dc:	8f998030 	lw	$t9,-32720($gp)

 -> load from 0x10000020
    (Wrong, this address isn't even mapped, see below!)

  4000e0:	00000000 	nop
  4000e4:	273900d0 	addiu	$t9,$t9,208
  4000e8:	0320f809 	jalr	$t9
  4000ec:	00000000 	nop
  4000f0:	03e00008 	jr	$ra
	...

nuke:     file format elf32-bigmips

Contents of section .got:
 10000000 00000000 80000000 004000d0 00000000  .........@......
 10000010 00000000 00000000 00000000 00000000  ................

This .got only contains one a pointer to the function hurz, but no the
expected pointer to 0x400000.

The pointer to hurz will never be referenced, btw, it's dead garbage in
the .got.  Making hurz a local function doesn't change that.

nuke:     file format elf32-bigmips

Program Header:
0x70000000 off    0x0000000000000094 vaddr 0x0000000000400094 paddr 0x0000000000400094 align 2**2
         filesz 0x0000000000000018 memsz 0x0000000000000018 flags r--
    LOAD off    0x0000000000000000 vaddr 0x0000000000400000 paddr 0x0000000000400000 align 2**12
         filesz 0x0000000000000100 memsz 0x0000000000000100 flags r-x
    LOAD off    0x0000000000001000 vaddr 0x0000000010000000 paddr 0x0000000010000000 align 2**12
         filesz 0x0000000000000020 memsz 0x0000000000000020 flags rw-
private flags = 5: [no abi set] [mips1] [not 32bitmode]

Seems the .got is quite a bit too large in our little test case ...

  Ralf

#!/bin/sh
# This is a shell archive (produced by GNU sharutils 4.2).
# To extract the files from this archive, save it to some FILE, remove
# everything before the `!/bin/sh' line above, then type `sh FILE'.
#
# Made on 1999-08-05 04:08 MEST by <ralf@gnu.org>
# Source directory was `/home/ralf/src/binutils'.
#
# Existing files will *not* be overwritten unless `-c' is specified.
#
# This shar contains:
# length mode       name
# ------ ---------- ------------------------------------------
#    236 -rw-rw-r-- nuke-ld-9/Makefile
#    129 -rw-rw-r-- nuke-ld-9/s2.s
#     18 -rw-rw-r-- nuke-ld-9/s1.s
#
echo=echo
touch -am 1231235999 $$.touch >/dev/null 2>&1
if test ! -f 1231235999 && test -f $$.touch; then
  shar_touch=touch
else
  shar_touch=:
  echo
  $echo 'WARNING: not restoring timestamps.  Consider getting and'
  $echo "installing GNU \`touch', distributed in GNU File Utilities..."
  echo
fi
rm -f 1231235999 $$.touch
#
if mkdir _sh23252; then
  $echo 'x -' 'creating lock directory'
else
  $echo 'failed to create lock directory'
  exit 1
fi
# ============= nuke-ld-9/Makefile ==============
if test ! -d 'nuke-ld-9'; then
  $echo 'x -' 'creating directory' 'nuke-ld-9'
  mkdir 'nuke-ld-9'
fi
if test -f 'nuke-ld-9/Makefile' && test "$first_param" != -c; then
  $echo 'x -' SKIPPING 'nuke-ld-9/Makefile' '(file already exists)'
else
  $echo 'x -' extracting 'nuke-ld-9/Makefile' '(text)'
  sed 's/^X//' << 'SHAR_EOF' > 'nuke-ld-9/Makefile' &&
AS = mips-linux-as
LD = mips-linux-ld
OBJDUMP = mips-linux-objdump
X
ASFLAGS = -KPIC
X
all: nuke
X
X.PHONY: nuke
X
nuke: s1.o s2.o
X	$(LD) -o $@ -e 0 $^
X	$(OBJDUMP) -d $@
X
X.PHONY: clean distclean
X
clean distclean:
X	-rm -f nuke s1.o s2.o core
SHAR_EOF
  $shar_touch -am 0805040699 'nuke-ld-9/Makefile' &&
  chmod 0664 'nuke-ld-9/Makefile' ||
  $echo 'restore of' 'nuke-ld-9/Makefile' 'failed'
  if ( md5sum --help 2>&1 | grep 'sage: md5sum \[' ) >/dev/null 2>&1 \
  && ( md5sum --version 2>&1 | grep -v 'textutils 1.12' ) >/dev/null; then
    md5sum -c << SHAR_EOF >/dev/null 2>&1 \
    || $echo 'nuke-ld-9/Makefile:' 'MD5 check failed'
9df8cafbb6403d86975f9ee4d6c6e81a  nuke-ld-9/Makefile
SHAR_EOF
  else
    shar_count="`LC_ALL= LC_CTYPE= LANG= wc -c < 'nuke-ld-9/Makefile'`"
    test 236 -eq "$shar_count" ||
    $echo 'nuke-ld-9/Makefile:' 'original size' '236,' 'current size' "$shar_count!"
  fi
fi
# ============= nuke-ld-9/s2.s ==============
if test -f 'nuke-ld-9/s2.s' && test "$first_param" != -c; then
  $echo 'x -' SKIPPING 'nuke-ld-9/s2.s' '(file already exists)'
else
  $echo 'x -' extracting 'nuke-ld-9/s2.s' '(text)'
  sed 's/^X//' << 'SHAR_EOF' > 'nuke-ld-9/s2.s' &&
X		nop;nop;nop;nop
X
X		.ent	hurz
X		#.globl	hurz
hurz:		.set	noreorder
X		.cpload	$25
X		.set	reorder
X		jal	hurz
X		jr	$31
X		.end	hurz
SHAR_EOF
  $shar_touch -am 0805040299 'nuke-ld-9/s2.s' &&
  chmod 0664 'nuke-ld-9/s2.s' ||
  $echo 'restore of' 'nuke-ld-9/s2.s' 'failed'
  if ( md5sum --help 2>&1 | grep 'sage: md5sum \[' ) >/dev/null 2>&1 \
  && ( md5sum --version 2>&1 | grep -v 'textutils 1.12' ) >/dev/null; then
    md5sum -c << SHAR_EOF >/dev/null 2>&1 \
    || $echo 'nuke-ld-9/s2.s:' 'MD5 check failed'
5ea0d57b5e76dc86afed35e8a4c4a9b4  nuke-ld-9/s2.s
SHAR_EOF
  else
    shar_count="`LC_ALL= LC_CTYPE= LANG= wc -c < 'nuke-ld-9/s2.s'`"
    test 129 -eq "$shar_count" ||
    $echo 'nuke-ld-9/s2.s:' 'original size' '129,' 'current size' "$shar_count!"
  fi
fi
# ============= nuke-ld-9/s1.s ==============
if test -f 'nuke-ld-9/s1.s' && test "$first_param" != -c; then
  $echo 'x -' SKIPPING 'nuke-ld-9/s1.s' '(file already exists)'
else
  $echo 'x -' extracting 'nuke-ld-9/s1.s' '(text)'
  sed 's/^X//' << 'SHAR_EOF' > 'nuke-ld-9/s1.s' &&
X		nop;nop;nop;nop
SHAR_EOF
  $shar_touch -am 0805031599 'nuke-ld-9/s1.s' &&
  chmod 0664 'nuke-ld-9/s1.s' ||
  $echo 'restore of' 'nuke-ld-9/s1.s' 'failed'
  if ( md5sum --help 2>&1 | grep 'sage: md5sum \[' ) >/dev/null 2>&1 \
  && ( md5sum --version 2>&1 | grep -v 'textutils 1.12' ) >/dev/null; then
    md5sum -c << SHAR_EOF >/dev/null 2>&1 \
    || $echo 'nuke-ld-9/s1.s:' 'MD5 check failed'
836a4f9e4106ebe8e16326239e8cdda1  nuke-ld-9/s1.s
SHAR_EOF
  else
    shar_count="`LC_ALL= LC_CTYPE= LANG= wc -c < 'nuke-ld-9/s1.s'`"
    test 18 -eq "$shar_count" ||
    $echo 'nuke-ld-9/s1.s:' 'original size' '18,' 'current size' "$shar_count!"
  fi
fi
rm -fr _sh23252
exit 0

Re: R_MIPS_GOT16 bug

[Mark Mitchell]

>>>>> "Ralf" == Ralf Baechle <ralf@uni-koblenz.de> writes:

    Ralf> It's worse, the size of the .got for perl(1) has increased
    Ralf> by a factor of two; for other non-trivial binaries I've
    Ralf> observed a factor of four.  Some pathological cases are even
    Ralf> worse.

Hmm.  Remind me of which of your test-cases shows the explosion, and
I'll investigate further.  It will probably take me into next week to
get a chance to look at this, but I will do so.

The original code as under-allocating GOT space; it was assuming that
certain relocations would always have the same GOT entry, when there's
no reason that they should.  I'll look for a way to find a middle
ground.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: R_MIPS_GOT16 bug

[Ralf Baechle]

On Sun, Aug 15, 1999 at 03:50:22PM -0700, Mark Mitchell wrote:

> >>>>> "Ralf" == Ralf Baechle <ralf@uni-koblenz.de> writes:
> 
>     Ralf> It now has become an issue of correctness as well.  Even a
>     Ralf> relativly small program like vim when configured with perl,
>     Ralf> python and X support reaches the size where we run out of
>     Ralf> GOT space.
> 
> I'm a little bit confused.  I wouldn't have thought things were
> *worse* than they were before.  Are they?  If so, I'll have to look at
> the old code and see what was working differently.

It's worse, the size of the .got for perl(1) has increased by a factor
of two; for other non-trivial binaries I've observed a factor of four.
Some pathological cases are even worse.

  Ralf

Re: R_MIPS_GOT16 bug

[Mark Mitchell]

>>>>> "Ralf" == Ralf Baechle <ralf@uni-koblenz.de> writes:

    Ralf> It now has become an issue of correctness as well.  Even a
    Ralf> relativly small program like vim when configured with perl,
    Ralf> python and X support reaches the size where we run out of
    Ralf> GOT space.

I'm a little bit confused.  I wouldn't have thought things were
*worse* than they were before.  Are they?  If so, I'll have to look at
the old code and see what was working differently.

    Ralf> As you say it looks non-trivial; is this on your agenda for
    Ralf> the next time?

Well, there's no `the next time' at this point.  Obviously, I'm open
to additional contracts, but the only action currently contracted is
fixing the kind of bugs you're reporting; I'm obligated to leave
things in a state no worse than that in which I found them.  So, if
this has really gotten worse, I'll do my best to fix it.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: R_MIPS_GOT16 bug

[Ralf Baechle]

On Fri, Aug 06, 1999 at 12:45:35PM -0700, Mark Mitchell wrote:

>     Ralf> Btw, the got in the executable seems to be quite bloated by
>     Ralf> alot of apparently unused entries.  My test case #10 has two
>     Ralf> reserved entries, two used ones and 13 unused ones.  The
>     Ralf> ranlib binary which I've just dissected seems to have just
>     Ralf> 14 used ones but in total 3737 allocated local got entries,
>     Ralf> that's almost 15kb wasted.
> 
> Yup.  That's a harder problem to fix; it requires asembling the GOT in
> a rather more clever way.  It would be nice to do, though!  Let's
> tackle correctness first; then we can get to this.

It now has become an issue of correctness as well.  Even a relativly small
program like vim when configured with perl, python and X support reaches
the size where we run out of GOT space.

As you say it looks non-trivial; is this on your agenda for the next time?

  Ralf