On Thu, Aug 18, 2011 at 03:37:15PM +0200, Michael Matz wrote:
> On Wed, 17 Aug 2011, Jed Davis wrote:
>
> > One thing I'm not so sure about is accepting any SYMBOLIC_CONST as a
> > legitimate address. That allows, for example, a symbol address cast
> > to uintptr_t and added to (6ULL << 32), whic
Hi,
On Wed, 17 Aug 2011, Jed Davis wrote:
> One thing I'm not so sure about is accepting any SYMBOLIC_CONST as a
> legitimate address. That allows, for example, a symbol address cast
> to uintptr_t and added to (6ULL << 32), which will never fit. On the
> other hand, -fPIC allows offsets of up
Second attempt: I now have a modified GCC 4.4.3 which recognizes
-mcmodel=smallhigh; in CM_SMALLHIGH, pic_32bit_operand acts as it does
for PIC (to get lea instead of movabs), and legitimate_address_p accepts
SYMBOLIC_CONSTs with no indexing (for anything with a memory constraint).
Beyond that, th
On Tue, Aug 09, 2011 at 04:26:06PM -0700, Jed Davis wrote:
> Thus, I'm trying to find the right solution. My current attempt is to
> add an -mno-plt flag in i386.opt, and add it to the list of reasons not
> to print "@PLT" after symbol names. This seems to work, although I've
> only done minimal
On Tue, Aug 09, 2011 at 04:58:01PM -0700, Andrew Pinski wrote:
> On Tue, Aug 9, 2011 at 4:26 PM, Jed Davis wrote:
> > The existing workaround, which predates my personal involvement, is to
> > use -fPIE together with a -include'd file that uses a #pragma to set the
> > default symbol visibility to
Jed Davis writes:
>
> But is that the right way to do that, do people think? Or should I
> look into making this its own -mcmodel option? (Which would raise the
I would make it a new -mcmodel=... option.
> question of what to call it -- medsmall? smallhigh? altkernel?) Or is
smallhigh sounds
On Tue, Aug 9, 2011 at 4:26 PM, Jed Davis wrote:
> The existing workaround, which predates my personal involvement, is to
> use -fPIE together with a -include'd file that uses a #pragma to set the
> default symbol visibility to hidden, which suppresses the PLTness.
> That works on GCC 4.1, but wit
The vSphere Hypervisor (ESXi) kernel runs on x86_64 and loads all text
and data sections (for the kernel itself and for modules) within a 2GB
window that lives around virtual address 0x4180 (65.5 TiB).
Thus, 32-bit absolute addresses won't work, but %rip-relative addressing
is fine. Addit
