Displaying 5 results from an estimated 5 matches for "0xfffffe".
Did you mean:
0xffffff
2016 Oct 07
2
Proposal: arbitrary relocations in constant global initializers
...is syntax the most:
> >> >>
> >> >> i32 reloc (29, void ()* @f, 3925868544)
> >> >> ; 29 = 0x1d = R_ARM_JUMP24
> >> >> ; 3925868544 = 0xea000000
> >> >>
> >> >> Note the zeroes in the relocated data instead of 0xfffffe in the
> >> >> original proposal. This is aligned with the way LLVM emits
> relocations
> >> >> in the backend, and avoids encoding the addend in a
> >> >> relocation-specific way in the IR.
> >> >
> >> >
> >> > I a...
2016 Oct 07
2
Proposal: arbitrary relocations in constant global initializers
...ned in this
> >> thread, and so far I like this syntax the most:
> >>
> >> i32 reloc (29, void ()* @f, 3925868544)
> >> ; 29 = 0x1d = R_ARM_JUMP24
> >> ; 3925868544 = 0xea000000
> >>
> >> Note the zeroes in the relocated data instead of 0xfffffe in the
> >> original proposal. This is aligned with the way LLVM emits relocations
> >> in the backend, and avoids encoding the addend in a
> >> relocation-specific way in the IR.
> >
> >
> > I am confused by this statement. If the zeros aren't what...
2016 Oct 07
2
Proposal: arbitrary relocations in constant global initializers
...gt; I've tried implementing some of the alternatives mentioned in this
> thread, and so far I like this syntax the most:
>
> i32 reloc (29, void ()* @f, 3925868544)
> ; 29 = 0x1d = R_ARM_JUMP24
> ; 3925868544 = 0xea000000
>
> Note the zeroes in the relocated data instead of 0xfffffe in the
> original proposal. This is aligned with the way LLVM emits relocations
> in the backend, and avoids encoding the addend in a
> relocation-specific way in the IR.
I am confused by this statement. If the zeros aren't what appear in the
object file, it seems rather relocation s...
2015 Aug 26
2
Proposal: arbitrary relocations in constant global initializers
On Wed, Aug 26, 2015 at 03:53:33PM -0400, Rafael Espíndola wrote:
> > I'm not sure if this would be sufficient. The R_ARM_JUMP24 relocation
> > on ARM has specific semantics to implement ARM/Thumb interworking; see
> > http://infocenter.arm.com/help/topic/com.arm.doc.ihi0044e/IHI0044E_aaelf.pdf
> > Note that R_ARM_CALL has the same operation but different semantics.
2016 Jan 30
4
Bug#810379: [Xen-devel] [BUG] pci-passthrough generates "xen:events: Failed to obtain physical IRQ" for some devices
On Wed, Jan 27, 2016 at 7:30 PM, Konrad Rzeszutek Wilk <
konrad.wilk at oracle.com> wrote:
> On Sat, Jan 23, 2016 at 05:12:04PM +0100, Tommi Airikka wrote:
> > Xen developers,
> >
> > After an upgrade of my Debian Jessie dom0 and domUs, my passthroughed
> > NIC stopped working.
> > This bug was probably introduced in Debian Jessie sometime
> > between