Displaying 5 results from an estimated 5 matches for "__imp_foo".
2015 Aug 13
2
[lld] Alias in COFF short import library.
>
> If you want to define an alias symbol "bar" to "foo" (which is an
> extension you want to provide), one way is to create an object file that
> defines "bar" and "__imp_bar" as aliases to "foo" and "__imp_foo",
> respectively, and add that object file to the import library. As a result,
> the import library file defines four symbols, {,__imp_}{foo,bar}.
>
> Do you know how to define symbol aliases in COFF? If you don't, take a
> look a member of oldnames.lib (which comes with MSV...
2015 Aug 13
2
[lld] Alias in COFF short import library.
>
> The header of libuser32b.a says that it defines MessageBoxB and
> __imp_MessageBoxB, but the import library file in the archive actually
> defines MessageBoxA (not B). So the archive file is broken. You may want to
> fix the header and try again.
Yes this is how I done the alias.
If you consider this invalid then look at libuser32.a
The header defines MessageBoxA and
2018 Dec 13
2
Crashes when adding VisualStduio generated object files to the JIT process
Hello everyone,
I'm using the LLVM for a JIT-Client under Windows 64bit. I tried various stuff with it and noticed, that object files or libraries which are generated by the Visual Studio Compiler 2015 or 2017 will break the jitted code, when they are added to the process.
I opened a bug for this a while ago (https://bugs.llvm.org/show_bug.cgi?id=39447) - sadly this bug will become a stopper
2013 Apr 23
0
[LLVMdev] Feedback required on proper dllexport/import implementation
Hi Nico, Reid, and Anton,
I missed the discussion when I implemented dllexport/dllimport for our local tree. I
essentially implemented your approach#1. I was trying to avoid the various
external_linkage + some_attribute approaches because it seems that external_linkage
would imply the external linkage without the dllimport/dllexport semantics, and there
may be existing compiler codes that rely on
2013 Mar 26
6
[LLVMdev] Feedback required on proper dllexport/import implementation
Hello,
while improving and extending support for dllexport/import I have
noticed that the current way these are implemented is problematic and I
would like some input on how to proceed.
Currently dllexport/dllimport is treated as linkage type. This conflicts
with inlined functions because there is no linkage for the combination
of both. On first though, combining both doesn't make sense, but