* Re: R_MIPS_GOT16 bug
[not found] ` <19990806124535D.mitchell@codesourcery.com>
@ 1999-08-15 15:31 ` Ralf Baechle
1999-08-15 15:46 ` Mark Mitchell
0 siblings, 1 reply; 5+ messages in thread
From: Ralf Baechle @ 1999-08-15 15:31 UTC (permalink / raw)
To: Mark Mitchell; +Cc: binutils
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: R_MIPS_GOT16 bug
1999-08-15 15:31 ` R_MIPS_GOT16 bug Ralf Baechle
@ 1999-08-15 15:46 ` Mark Mitchell
1999-08-15 15:52 ` Ralf Baechle
0 siblings, 1 reply; 5+ messages in thread
From: Mark Mitchell @ 1999-08-15 15:46 UTC (permalink / raw)
To: ralf; +Cc: binutils
>>>>> "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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: R_MIPS_GOT16 bug
1999-08-15 15:46 ` Mark Mitchell
@ 1999-08-15 15:52 ` Ralf Baechle
1999-08-15 15:59 ` Mark Mitchell
0 siblings, 1 reply; 5+ messages in thread
From: Ralf Baechle @ 1999-08-15 15:52 UTC (permalink / raw)
To: Mark Mitchell; +Cc: binutils
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: R_MIPS_GOT16 bug
1999-08-15 15:52 ` Ralf Baechle
@ 1999-08-15 15:59 ` Mark Mitchell
0 siblings, 0 replies; 5+ messages in thread
From: Mark Mitchell @ 1999-08-15 15:59 UTC (permalink / raw)
To: ralf; +Cc: binutils
>>>>> "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
^ permalink raw reply [flat|nested] 5+ messages in thread
* R_MIPS_GOT16 bug
@ 1999-08-04 19:14 Ralf Baechle
0 siblings, 0 replies; 5+ messages in thread
From: Ralf Baechle @ 1999-08-04 19:14 UTC (permalink / raw)
To: Mark Mitchell, binutils
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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~1999-08-15 15:59 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <19990806035519.B872@uni-koblenz.de>
[not found] ` <19990805192859R.mitchell@codesourcery.com>
[not found] ` <19990806170650.A1366@uni-koblenz.de>
[not found] ` <19990806124535D.mitchell@codesourcery.com>
1999-08-15 15:31 ` R_MIPS_GOT16 bug Ralf Baechle
1999-08-15 15:46 ` Mark Mitchell
1999-08-15 15:52 ` Ralf Baechle
1999-08-15 15:59 ` Mark Mitchell
1999-08-04 19:14 Ralf Baechle
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).