This is the mail archive of the 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:58 PM, David Miller <> wrote:
> From: "H.J. Lu" <>
> Date: Thu, 22 Apr 2010 18:46:14 -0700
>> The idea of 2MB maximum page size is we may use variable
>> page size one day without recompiling everything.
> Indeed.
> Because it's 64k on sparc (even 32-bit) I was at least able to
> experiment with such things.

It is very unfortunate that binaries created by gold can't take
advantage of variable page size.

> In fact doesn't the x86_64 specification explicitly state that the
> default maximum page size is to be 2MB in ELF objects?

I saw

3.3.3 Page Size
Systems are permitted to use any power-of-two page size between 4KB and 64KB,

in x86-64 psABI.

> Finally, I really don't personally buy the argument that the 64-bit
> address space will be seriously taken close to exhaustion due to a 2MB
> maximum page size, even with hundreds of shared libraries. ?We have
> 2^32 times (or a similar order of magnitude) more address space
> available than on 32-bit.

Ian's issue is they want to limit the size of virtual memory:

cputime         unlimited
filesize        unlimited
datasize        unlimited
stacksize       8MB
coredumpsize    0kB
memoryuse       unlimited
maxproc         30985
descriptors     1024
memorylocked    64kB
addressspace    unlimited
maxfilelocks    unlimited
sigpending      30985
msgqueue        819200
nice            0
rt_priority     0

Personally I think they can set memory size limit on a per-process/login/binary
basis via other tools, like pam, without using 4K page size on x86-64.
Gold and ld should use the same maximum page size on x86-64.


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