[cfe-dev] linux/i386 and mregparm

[pageexec at freemail.hu]

On 1 Mar 2011 at 22:59, Anton Korobeynikov wrote:

> > for the non-rip relative case i don't see why accepting negative offsets is
> > wrong whereas it's considered correct for the small model. i.e., what is the
> > programming construct that
> >  1. produces such negative offsets and
> >  2. is correct for small mode and
> >  3. is wrong for the kernel?
> According to x86-64 ABI (see
> http://www.x86-64.org/documentation/abi.pdf, section 3.5.1 for more
> information), kernel resides in negative 32 bit space.
> This means that if we'll have negative offset here it might just wrap
> around and we won't be able to fit the stuff into 32 bit and have very
> big positive addresses. See the note in that section about the offsets
> wrt symbolic references.

the same is true for the positive 32 (well, 31) bit address space where
the main executable resides yet clang doesn't forbid *all* positive offsets
on grounds that they may wrap and address the negative address space.

> PS: gcc behaves the same way wrt negative offsets for kernel code model.

example from an amd64 linux kernel:

fff8305dd7e:       48 8b 35 eb 05 e5 ff    mov    -0x1afa15(%rip),%rsi        # ffffffff82eae370 <key_type_dns_resolver>

this negative offset is what is caught by the existing check. now whether
it should end up in there or not, i can't tell (it may be a bug), but as
i said, i needed a quick hack to get rip relative addressing to work so i
just went with disabling this range check. if there's a better, i'm all
ears ;).