This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]