This is the mail archive of the
mailing list for the GCC project.
x86_64 -mcmodel=smallhigh, cont'd
- From: Jed Davis <jedidiah at vmware dot com>
- To: gcc at gcc dot gnu dot org
- Date: Tue, 17 Jan 2012 13:20:10 -0800
- Subject: x86_64 -mcmodel=smallhigh, cont'd
I posted about this a few months ago, but I've been busy with
higher-priority work until recently, so I've only just picked it back up,
but I think I've fixed the last bug.
To review: my goal is to give the x86 backend a code model where code and
data reside within an arbitrary 2GiB of the address space, and where the
loader/runtime is not required to support the ELF PIC facilities.
The motivating example for this is the vSphere Hypervisor (ESXi) kernel
and its modules, which are loaded outside the range of both the "small"
and "kernel" models of the x86_64 ABI for technical reasons which,
for the sake of brevity, I will not attempt to explain here. This
being a kernel environment and not a "shared text" user program, text
relocations are free; thus, the overhead of PLT/GOT indirection is
unnecessary and, indeed, unwelcome.
Implementing this code model appears to be relatively simple: legitimate
addresses are computed as for CM_SMALL_PIC but treating every symbol
as local, and any constant_address_p immediate can be loaded with lea
instead of movabs.
As before, if it sounds like I'm still doing this wrong, that would be
nice to know; this project is more or less my first nontrivial exposure
to GCC internals.
Our legal department appears to be fine with contributing this back,
although I want to wait until I get specific confirmation before mailing
any diffs. At the moment I have diffs against 4.4.3 (yes, I know it's
old) and HEAD, but they still need documentation changes and testcases
before they'd be useful.
But my other question is: is there interest in having this change
contributed? It's not inherently vendor-specific, but I'm having trouble
thinking of anyone else who'd want to use it, and I don't know what GCC's
policy is on features like that.