This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
offseting DATA_ADDR
- From: Matt Thomas <matt at 3am-software dot com>
- To: binutils at sourceware dot org
- Date: Mon, 21 Sep 2009 11:12:22 -0700
- Subject: offseting DATA_ADDR
[I've wondered about this for years and I'm finally going to ask it.]
Why isn't DATA_ADDR/SHLIB_DATA_ADDR defined by default to start on a
segment boundary?
Why is it defined to start at about the same offset as where text ends
by default?
For example, a MIPS N32 shared library has the following load sections
by default:
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg
Align
LOAD 0x000000 0x00000000 0x00000000 0xfc140 0xfc140 R E
0x10000
LOAD 0x0fc140 0x001fc140 0x001fc140 0x071c0 0x17300 RW
0x10000
If I change DATA_ADDR/SHLIB_DATA_ADDR to be defined as ALIGN($
{SEGMENT_SIZE}), I get:
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg
Align
LOAD 0x000000 0x00000000 0x00000000 0xfc140 0xfc140 R E
0x10000
LOAD 0x100000 0x00100000 0x00100000 0x071c0 0x17300 RW
0x10000
That seems to me to be a much more sane layout. What does the extra
0xfc140 offset buy me? There is a cost overhead to that wasted space
(unused PTEs in the kernel, can't easily use large page sizes
for .data).
I can see that it might be used in a small set of cases (ROM images
copied to ram) but in the vast majority of normal usage it seems to
just waste address space.
Can anyone enlighten me?