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), which will never fit. On the > > other hand, -fPIC allows offsets of up to +/- 16Mib for some unexplained > > reason, > > The x86-64 ABI specifies this. All symbols have to be located between 0x0 > and 2^31-2^24-1, and that is so that everything in memory objects of > length less than 2^24 can be addressed directly.
Oh, of course. For some reason I went through the ELF spec, but didn't think to see what the x86_64 ABI had to say about code models. Everything makes much more sense now. Thanks for the pointer. > Otherwise only the base address of symbols would be addressable > directly and any offsetted variant would have to be calculated > explicitely. Right; that's what I was trying to avoid doing. It looks like I can reuse legitimate_pic_address_disp_p for this; this is not quite PIC, but the same set of non-immediate displacement-only addresses is usable in general operands. Except that then pic_32bit_operand does the wrong thing, because actual PIC has hooks in the MI recog.c that affect the constraints (I think?), and I don't. But... what "pic_32bit_operand" actually means is "can I use LEA to obtain this value?", and anything that's a legitimate address in strict RTL can be LEA'ed. So that takes care of that. Back to testing, I guess. --Jed
