From: "Joakim Tjernlund" <joakim.tjernlund@lumentis.se>
To: "Linuxppc-Dev@Lists. Linuxppc. Org (E-mail)"
<linuxppc-dev@lists.linuxppc.org>
Subject: TASK_UNMAPPED_BASE
Date: Tue, 3 Feb 2004 14:05:20 +0100 [thread overview]
Message-ID: <000501c3ea56$60935060$0a01a8c0@LUMENTIS02> (raw)
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:
{
Elf32_Sword delta = finaladdr - (Elf32_Word) reloc_addr;
if (delta << 6 >> 6 == delta)
*reloc_addr = OPCODE_B (delta);
else if (finaladdr <= 0x01fffffc || finaladdr >= 0xfe000000)
*reloc_addr = OPCODE_BA (finaladdr);
else
{
Elf32_Word *plt, *data_words;
Elf32_Word index, offset, num_plt_entries;
plt = (Elf32_Word *) D_PTR (map, l_info[DT_PLTGOT]);
offset = reloc_addr - plt;
if (offset < PLT_DOUBLE_SIZE*2 + PLT_INITIAL_ENTRY_WORDS)
{
index = (offset - PLT_INITIAL_ENTRY_WORDS)/2;
num_plt_entries = (map->l_info[DT_PLTRELSZ]->d_un.d_val
/ sizeof(Elf32_Rela));
data_words = plt + PLT_DATA_START_WORDS (num_plt_entries);
data_words[index] = finaladdr;
reloc_addr[0] = OPCODE_LI (11, index * 4);
reloc_addr[1] = OPCODE_B ((PLT_LONGBRANCH_ENTRY_WORDS
- (offset+1))
* 4);
MODIFIED_CODE_NOQUEUE (reloc_addr + 1);
}
else
{
reloc_addr[0] = OPCODE_LIS_HI (12, finaladdr);
reloc_addr[1] = OPCODE_ADDI (12, 12, finaladdr);
reloc_addr[2] = OPCODE_MTCTR (12);
reloc_addr[3] = OPCODE_BCTR ();
MODIFIED_CODE_NOQUEUE (reloc_addr + 3);
}
}
}
break;
The if (delta << 6 >> 6 == delta) is commonly false.
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.
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?
Jocke
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
next reply other threads:[~2004-02-03 13:05 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-03 13:05 Joakim Tjernlund [this message]
2004-02-03 15:22 ` TASK_UNMAPPED_BASE Franz Sirl
2004-02-03 16:51 ` TASK_UNMAPPED_BASE Joakim Tjernlund
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='000501c3ea56$60935060$0a01a8c0@LUMENTIS02' \
--to=joakim.tjernlund@lumentis.se \
--cc=linuxppc-dev@lists.linuxppc.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 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 NNTP newsgroup(s).