search for: 00000143

Displaying 3 results from an estimated 3 matches for "00000143".

Did you mean: 00000103
2017 Jun 06
2
[newbie] trouble with global variables and CreateLoad/Store in JIT
...4 05 00 00 00 je 5 <_XEP:getfoo+0x12> > 13d: e8 00 00 00 00 calll 0 <_XEP:getfoo+0x12> > 0000013e: IMAGE_REL_I386_REL32 _typeError > 142: e8 00 00 00 00 calll 0 <_XEP:getfoo+0x17> > 00000143: IMAGE_REL_I386_REL32 _getfoo > 147: c3 retl > > > On Tue, Jun 6, 2017 at 3:18 AM, Sean Silva <chisophugis at gmail.com> wrote: > >> >> >> On Mon, Jun 5, 2017 at 1:34 PM, Nikodemus Siivola < >> nikodemus at random-state.net> wrote:...
2017 Jun 07
2
[newbie] trouble with global variables and CreateLoad/Store in JIT
...t;_XEP:getfoo+0x12> >>> 13d: e8 00 00 00 00 calll 0 <_XEP:getfoo+0x12> >>> 0000013e: IMAGE_REL_I386_REL32 _typeError >>> 142: e8 00 00 00 00 calll 0 <_XEP:getfoo+0x17> >>> 00000143: IMAGE_REL_I386_REL32 _getfoo >>> 147: c3 retl >>> >>> >>> On Tue, Jun 6, 2017 at 3:18 AM, Sean Silva <chisophugis at gmail.com> >>> wrote: >>> >>>> >>>> >>>> On Mon, Jun 5, 2017 at 1:34...
2017 Jun 06
2
[newbie] trouble with global variables and CreateLoad/Store in JIT
On Mon, Jun 5, 2017 at 1:34 PM, Nikodemus Siivola < nikodemus at random-state.net> wrote: > Uh. Turns out that if I hide the pointer to @foo from LLVM by passing it > through an opaque identity function ... then everything works fine. > > Is this a bug in LLVM or is there some magic involving globals I'm > misunderstanding? > This looks like a bug in the handling of