From: "Joakim Tjernlund" <Joakim.Tjernlund@lumentis•se>
To: "Franz Sirl" <Franz.Sirl-ppc@lauterbach•com>
Cc: "Linuxppc-Dev@Lists. Linuxppc. Org (E-mail)"
<linuxppc-dev@lists•linuxppc.org>
Subject: Re: TASK_UNMAPPED_BASE
Date: Tue, 3 Feb 2004 17:51:03 +0100 [thread overview]
Message-ID: <002501c3ea75$eb7eba10$020120b0@jockeXP> (raw)
In-Reply-To: 6.0.2.0.2.20040203161335.035fde58@mail.lauterbach.com
Hi Franz
Thanks for replying.
> At 14:05 03.02.2004, Joakim Tjernlund wrote:
>
> >Hi All
> >
> >Currently TASK_UNMAPPED_BASE in PPC is defined to:
> >#define TASK_UNMAPPED_BASE (TASK_SIZE / 8 *3) which is 0x30000000
> >
> >in glibc ldso's JMP_SLOT you have:
[SNIP]
> >
> >The if (delta << 6 >> 6 == delta) is commonly false.
>
> Well, if that is true for you, then you must have a really large app, since
> this covers relative branches +/-32M.
32M == 0x2000000 which is < 0x30000000-0x10000000
So "branches" to any library function will not fit into the 32M space, right?
>
> >If finaladdr is <= 0x01fffffc then the relocation is much cheaper than the
> >last else statement.
> >But since TASK_UNMAPPED_BASE is 0x30000000, finaladdr will never be <=
> >0x01fffffc unless
> >a shared library asks for a low address.
>
> But nearly nothing loads at 0x30000000, usually only ld.so. The executable
> itself (note that I haven't looked at PIE executables yet) is at 0x10000000
> and the shared libs are loaded initially below that until that space is
> filled and then above ld.so IIRC.
Yes, thats true for glibc. I wonder why glibc supply its own load address for all
libs but ld.so?
However, I forgot to mention uClibc. UClibc does not insist on its own load address, but lets
the kernel handle that. So for uClibc, ld.so will load at 0x30000000 and the rest will follow
after ld.so.
>
> >I changed TASK_UNMAPPED_BASE to well under 0x01fffffc and it worked as well.
> >
> >My question: Why is TASK_UNMAPPED_BASE=0x30000000 and would changing it to
> >something
> >less, say 0x00100000 be a problem?
>
> Hmm, might work, but it can also break in subtle ways, cause the shared lib
> loading algorithm makes a few assumptions about the used address ranges
> IIRC. But I don't see any use for it if you consider what I said above.
OK, but are there other considerations as well? What is the address space below 0x10000000 used for?
Jocke
>
> Franz.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2004-02-03 16:51 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-03 13:05 TASK_UNMAPPED_BASE Joakim Tjernlund
2004-02-03 15:22 ` TASK_UNMAPPED_BASE Franz Sirl
2004-02-03 16:51 ` Joakim Tjernlund [this message]
2004-02-04 14:37 ` TASK_UNMAPPED_BASE Peter Bergner
2004-02-04 14:47 ` TASK_UNMAPPED_BASE Anton Blanchard
2004-02-04 21:58 ` TASK_UNMAPPED_BASE Peter Bergner
2004-02-05 8:57 ` TASK_UNMAPPED_BASE Joakim Tjernlund
2004-02-05 16:34 ` TASK_UNMAPPED_BASE Peter Bergner
2004-02-05 17:06 ` TASK_UNMAPPED_BASE Anton Blanchard
2004-02-06 10:53 ` TASK_UNMAPPED_BASE Joakim Tjernlund
2004-02-05 17:10 ` TASK_UNMAPPED_BASE Joakim Tjernlund
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='002501c3ea75$eb7eba10$020120b0@jockeXP' \
--to=joakim.tjernlund@lumentis$(echo .)se \
--cc=Franz.Sirl-ppc@lauterbach$(echo .)com \
--cc=linuxppc-dev@lists$(echo .)linuxppc.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox