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]

Re: Help needed to track down bug: linking Linux kernel with gold creates unbootable kernel


On Thu, Apr 22, 2010 at 6:21 PM, Ian Lance Taylor <iant@google.com> wrote:
> "H.J. Lu" <hjl.tools@gmail.com> writes:
>
>> 2MB maximum page size may have a bigger gap between PT_LOAD
>> segment in memory than 4KB maximum page size. But it doesn't necessarily
>> use more memory nor disk space. Since x86_64 is 64bit, address
>> space shouldn't be an issue in vast majority cases. I'd like to hear
>> a case to say otherwise.
>
> The increased use of address space was an issue with x86_64 binaries
> which opened hundreds of shared libraries. ?Each shared library was
> burning 2 megabytes of address space between the text and data
> segments. ?This in turn caused trouble with setting limits on the
> amount of virtual memory which could be allocated: greatly increasing
> the limits to permit hundreds of shared libraries meant that the
> limits were unreasonably high for programs with only a couple of
> shared libraries. ?This was a problem we found with GNU ld a while
> back. ?While other workarounds were possible, using -z max-page-size
> was a simple one. ?I didn't see any reason to carry that problem
> forward with gold, given that extremely few programs need -z
> max-page-size larger than 0x1000 on x86_64.

So the issue is you want to use hundreds of shared libraries
and limit the virtual memory size. This is very unique to your
organization. Otherwise, we will hear many complaints over
the last few years.

The idea of 2MB maximum page size is we may use variable
page size one day without recompiling everything.


-- 
H.J.


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