From: "David S. Miller" <davem@davemloft.net>
To: sparclinux@vger.kernel.org
Subject: Re: mmap breakage
Date: Tue, 07 Dec 2004 06:06:26 +0000 [thread overview]
Message-ID: <20041206220626.3ae45a03.davem@davemloft.net> (raw)
In-Reply-To: <Pine.LNX.4.61.0412032354010.1963@bobcat>
On Tue, 7 Dec 2004 01:00:47 -0500 (EST)
Jurij Smakov <jurij@wooyd.org> wrote:
> On the sparclinux@vger list we have been recently discussing an issue of
> ld-linux.so.2 failing with SIGILL when executed directly with the
> executable name as an argument [0]. This problem was traced to the mmap
> call overwriting portions of ld-linux.so.2 itself. Insight provided by
> glibc people [1] helped to determine that on sparc64 the ld-linux.so.2
> is mapped at 0x08000000, leaving just 128MB for the executable.
Actually, Jurij when you run ldd on a 64-bit binary what does
it say? I can't reproduce that strange 0x08000000 address.
For me it seems to put ld-linux.so.2 at just the right spot:
davem@nuts:~$ file nanotest
nanotest: ELF 64-bit MSB executable, SPARC V9, version 1 (SYSV), for GNU/Linux 2.4.18, dynamically linked (uses shared libs), not stripped
davem@nuts:~$ ldd nanotest
libc.so.6 => /lib64/libc.so.6 (0xfffff80000120000)
/lib64/ld-linux.so.2 => /lib64/ld-linux.so.2 (0xfffff80000000000)
davem@nuts:~$
And actually executing the binary shows that it is in fact
mapped at 0xfffff80000000000.
davem@nuts:~$ cat /proc/1707/maps
00100000-00102000 r-xp 00000000 08:11 164461 /home/davem/nanotest
00200000-00202000 rwxp 00000000 08:11 164461 /home/davem/nanotest
7ffffffe000-80000000000 rw-p 7ffffffe000 00:00 0
fffff80000000000-fffff8000001c000 r-xp 00000000 08:11 894371 /lib64/ld-2.3.2.so
fffff8000001c000-fffff8000001e000 rw-p fffff8000001c000 00:00 0
fffff8000011c000-fffff8000011e000 rwxp 0001c000 08:11 894371 /lib64/ld-2.3.2.so
fffff80000120000-fffff80000276000 r-xp 00000000 08:11 895274 /lib64/libc-2.3.2.so
fffff80000276000-fffff80000320000 ---p 00156000 08:11 895274 /lib64/libc-2.3.2.so
fffff80000320000-fffff80000380000 rwxp 00100000 08:11 895274 /lib64/libc-2.3.2.so
fffff80000380000-fffff80000384000 rwxp fffff80000380000 00:00 0
davem@nuts:~$
next prev parent reply other threads:[~2004-12-07 6:06 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-04 5:22 mmap breakage Jurij Smakov
2004-12-04 23:13 ` Richard Mortimer
2004-12-04 23:16 ` Richard Mortimer
2004-12-06 4:30 ` Jurij Smakov
2004-12-06 5:23 ` David S. Miller
2004-12-07 6:00 ` Jurij Smakov
2004-12-07 6:06 ` David S. Miller [this message]
2004-12-07 6:11 ` Keith M Wesolowski
2004-12-07 6:20 ` David S. Miller
2004-12-07 6:31 ` Jurij Smakov
2004-12-07 7:47 ` David S. Miller
2004-12-07 8:24 ` Jakub Jelinek
2004-12-07 15:38 ` Jurij Smakov
2004-12-08 0:54 ` Richard Mortimer
2004-12-09 5:24 ` David S. Miller
2004-12-09 7:34 ` David S. Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20041206220626.3ae45a03.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=sparclinux@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.