From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Thu, 15 May 2014 15:42:15 -0400 To: 9fans@9fans.net Message-ID: In-Reply-To: <3abad098ea8858c664eda80dd68493e5@felloff.net> References: <3abad098ea8858c664eda80dd68493e5@felloff.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] linking a program to run at a high address Topicbox-Message-UUID: e68713ac-ead8-11e9-9d60-3106f5b1d025 On Thu May 15 15:19:39 EDT 2014, cinap_lenrek@felloff.net wrote: > that wont work for a.out userspace binary. the kernel loads > the text segment on fixed base address UTZERO. in the a.out > header are just longs with the sizes of the segments. theres > an entry field but it doesnt change where the kernel puts the > text segment. >=20 > but you probably do not try to produce an a.out? there is a provision for a 64-bit address in the extended a.out header. =20 the problem is the amd64 architecture. ron actually pointed this out to = me way back, when i thought it would be neater to load the kernel lower than 0xfffffffff0110000 to allow the kernel to map more than 256mb of memory, but that's not possible. if using absolute addressing, the ke= rnel needs to load at a sign extended virtual address, or below 4g. if the ke= rnel were rip-relative, i beleve it could be just about anywhere in the virtua= l address space, but i haven't tried this and i may have missed a wherefore in the intel manual. it turns out that it's just as easy to load the data at KSEG2, so that's = what is done. in fact, perhaps KZERO should be moved up to 2=E2=81=B6=E2=81=B4= -64MB. then all the data could be in KSEG2. clean, if a little unconventional. - erik