[llvm-dev] Kaleidoscope on Windows - bug maybe found?

[Lang Hames via llvm-dev]

Hi Russell,

Thanks for looking in to this.

The root cause of this problem is in libObject - ELF and MachO objects both
set the Exported flag on their symbols correctly, but COFF currently does
not. The Right Thing to do here would be to fix libObject, but nobody has
found time for that yet. In the mean time the workaround you've discovered
works just fine.

- Lang.


On Thu, Mar 31, 2016 at 6:48 PM, Russell Wallace via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Addendum: this still fails:
>
>       auto ExprSymbol = J.findSymbol("putchard");
>
>  As yet, I have no idea why - that symbol even seemed to be exported:
>
> extern "C"
> double putchard(double X) {
>   putchar((char)X);
>   return 0;
> }
>
>
> On Fri, Apr 1, 2016 at 2:42 AM, Russell Wallace <russell.wallace at gmail.com
> > wrote:
>
>> To try to find out why it was crashing, I followed the trail of function
>> calls:
>>
>> C:\llvm\examples\Kaleidoscope\Orc\initial\toy.cpp
>>
>>       auto ExprSymbol = J.findUnmangledSymbol("__anon_expr");
>>
>>   JITSymbol findUnmangledSymbol(const std::string Name) {
>>     return findSymbol(mangle(Name));
>>   }
>>
>>   JITSymbol findSymbol(const std::string &Name) {
>>     return CompileLayer.findSymbol(Name, true);
>>   }
>>
>>   CompileLayerT CompileLayer;
>>   typedef IRCompileLayer<ObjLayerT> CompileLayerT;
>>
>> C:\llvm\include\llvm\ExecutionEngine\Orc\IRCompileLayer.h
>>
>> template <typename BaseLayerT> class IRCompileLayer {
>>
>>   JITSymbol findSymbol(const std::string &Name, bool ExportedSymbolsOnly)
>> {
>>     return BaseLayer.findSymbol(Name, ExportedSymbolsOnly);
>>   }
>>
>> C:\llvm\examples\Kaleidoscope\Orc\initial\toy.cpp
>>
>>   typedef ObjectLinkingLayer<> ObjLayerT;
>>
>> C:\llvm\include\llvm\ExecutionEngine\Orc\ObjectLinkingLayer.h
>>
>>   JITSymbol findSymbol(StringRef Name, bool ExportedSymbolsOnly) {
>>     for (auto I = LinkedObjSetList.begin(), E = LinkedObjSetList.end(); I
>> != E;
>>          ++I)
>>       if (auto Symbol = findSymbolIn(I, Name, ExportedSymbolsOnly))
>>         return Symbol;
>>
>>   JITSymbol findSymbolIn(ObjSetHandleT H, StringRef Name,
>>                          bool ExportedSymbolsOnly) {
>>     if (auto Sym = (*H)->getSymbol(Name)) {
>> C:\llvm\examples\Kaleidoscope\Orc\initial\toy.cpp
>>
>>       auto ExprSymbol = J.findUnmangledSymbol("__anon_expr");
>>
>>   JITSymbol findUnmangledSymbol(const std::string Name) {
>>     return findSymbol(mangle(Name));
>>   }
>>
>>   JITSymbol findSymbol(const std::string &Name) {
>>     return CompileLayer.findSymbol(Name, true);
>>   }
>>
>>   CompileLayerT CompileLayer;
>>   typedef IRCompileLayer<ObjLayerT> CompileLayerT;
>>
>> C:\llvm\include\llvm\ExecutionEngine\Orc\IRCompileLayer.h
>>
>> template <typename BaseLayerT> class IRCompileLayer {
>>
>>   JITSymbol findSymbol(const std::string &Name, bool ExportedSymbolsOnly)
>> {
>>     return BaseLayer.findSymbol(Name, ExportedSymbolsOnly);
>>   }
>>
>> C:\llvm\examples\Kaleidoscope\Orc\initial\toy.cpp
>>
>>   typedef ObjectLinkingLayer<> ObjLayerT;
>>
>> C:\llvm\include\llvm\ExecutionEngine\Orc\ObjectLinkingLayer.h
>>
>>   JITSymbol findSymbol(StringRef Name, bool ExportedSymbolsOnly) {
>>     for (auto I = LinkedObjSetList.begin(), E = LinkedObjSetList.end(); I
>> != E;
>>          ++I)
>>       if (auto Symbol = findSymbolIn(I, Name, ExportedSymbolsOnly))
>>         return Symbol;
>>
>>   JITSymbol findSymbolIn(ObjSetHandleT H, StringRef Name,
>>                          bool ExportedSymbolsOnly) {
>>     if (auto Sym = (*H)->getSymbol(Name)) {
>>       if (Sym.isExported() || !ExportedSymbolsOnly) {
>>
>> and after putting in some debugging code, it turns out this is it - the
>> client wants exported symbols only, but the expression is not exported.
>> This is the easiest change to fix the problem:
>>
>>   JITSymbol findSymbol(const std::string &Name) {
>>     return CompileLayer.findSymbol(Name, false);
>>   }
>>
>>  but is it the right one? Or should the symbol be exported instead?
>>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160404/c84b3d72/attachment.html>