search for: mcjithelper

Cheers Lang! You were right, I was testing this on Linux. I was planning on committing these changes with the corresponding changes to the Kaleidoscope tutorial walk-through. Might be a bit of a surprise to have no explanation of what MCJITHelper and friends is doing. I'll try and make time to prepare some patches along these lines, as well as updating future chapters with the same fix. Thanks for taking a look :) Charlie. On 16 January 2015 at 19:46, Lang Hames <lhames at gmail.com> wrote: > Committed in r226308. Thanks Ch...

...e> wrote: > Charlie Turner <charlesturner7c5 <at> gmail.com> writes: > > > I was planning on committing these changes with the corresponding > > changes to the Kaleidoscope tutorial walk-through. Might be a bit of a > > surprise to have no explanation of what MCJITHelper and friends is > > doing. > > > > I'll try and make time to prepare some patches along these lines, as > > well as updating future chapters with the same fix. > > > > Thanks for taking a look :) > > > Any progress on fixing the tutorial? > > I...

...r <charlesturner7c5 <at> gmail.com> writes: >>> >>> > I was planning on committing these changes with the corresponding >>> > changes to the Kaleidoscope tutorial walk-through. Might be a bit of a >>> > surprise to have no explanation of what MCJITHelper and friends is >>> > doing. >>> > >>> > I'll try and make time to prepare some patches along these lines, as >>> > well as updating future chapters with the same fix. >>> > >>> > Thanks for taking a look :) >>> &gt...

Oh - I know what this is. You were running this on Linux, right? On MacOS I think the symbol is getting double mangled while going through MCJIT::getSymbolAddress, hence the failure: The IR level foo function gets compiled to "_foo" in the object file, and then "_foo" gets mangled to "__foo" when we look it up. Linux doesn't do assembly level name-mangling, so