search for: drectve

...:\Program Files\Microsoft Visual Studio\VC98\Lib" -L"C:\Program Files\ Numerical Algorithms Group\CLW3207DA" -L"C:\Program Files\Numerical Algorithms Group\CLW3207DA\mkl\lib" -lLIBCMT -lnagcsmt-mkl -lmkl_s -lmkl_def -lmkl_lapack -lADVAPI32 -lNETAPI32 -lg2c -lR Warning: .drectve `%.*s' unrecognized Warning: .drectve `%.*s' unrecognized Warning: .drectve `%.*s' unrecognized Warning: .drectve `%.*s' unrecognized Warning: .drectve `%.*s' unrecognized Warning: .drectve `%.*s' unrecognized Warning: .drectve `%.*s' unrecognized Warning: .drectve `%.*s...

...\CLW3207DA\mkl\lib" -lLIBCMT -lnagcsmt-mkl -lmkl_s -lmkl_def > <http://www.murdochsutherland.com/Rtools/> >-lmkl_lapack > <http://www.murdochsutherland.com/Rtools/> >-lADVAPI32 -lNETAPI32 >-lg2c -lR > <http://www.murdochsutherland.com/Rtools/> >Warning: .drectve `%.*s' >unrecognized > <http://www.murdochsutherland.com/Rtools/> >Warning: .drectve `%.*s' >unrecognized > <http://www.murdochsutherland.com/Rtools/> >Warning: .drectve `%.*s' >unrecognized > <http://www.murdochsutherland.com/Rtools/> >Warni...

...eaders output.obj and see the following output: output.obj: file format COFF-x86-64 Sections: Idx Name Size Address Type 0 .text 00000012 0000000000000000 TEXT 1 .data 00000000 0000000000000000 DATA 2 .bss 00000000 0000000000000000 BSS 3 .drectve 00000018 0000000000000000 4 .xdata 00000008 0000000000000000 DATA 5 .pdata 0000000c 0000000000000000 DATA I don't think there's debugging information there, as the .text section is very small. Thanks, Peter

...t;Yunzhong.Gao at am.sony.com>wrote: > Hi Daniel, > > Nice to meet you. > > My understanding of the Microsoft #pragma comment(lib, ...) semantics is > that > each specified library will be converted into a directive that starts with > "/DEFAULTLIB" in the COFF .drectve section. To demonstrate, the following > patch > produces directives that work with Visual Studio 2010 using the > now-deprecated > dependent library feature (commits r168779 and r168694). > Is that feature now-deprecated? The documentation here: http://msdn.microsoft.com/en-us/li...

Hi Daniel, >> My understanding of the Microsoft #pragma comment(lib, ...) semantics is that >> each specified library will be converted into a directive that starts with >> "/DEFAULTLIB" in the COFF .drectve section. To demonstrate, the following patch >> produces directives that work with Visual Studio 2010 using the now-deprecated >> dependent library feature (commits r168779 and r168694). > Is that feature now-deprecated? The documentation here: > http://msdn.microsoft.com/en-us/...

...gt; components in LLD should be like this: > > Config: (nothing) > Core: Config > Driver: Core Passes ReaderWriter > Passes: Core ReaderWriter > ReaderWriter: Core (and Driver?) > > I don't want ReaderWriter to depend on Driver, but it may be unavoidable > because of .drectve section in PE/COFF which contains command line options. > Well, it *can't* depend on Driver if Driver depends on ReaderWriter. > > ReaderWriter should be able to be split into smaller libraries because > there's no cross-arch dependency between sub-directories in ReaderWriter...

Hi Rui, Rafael, Kevin, Nick, In r258665 I added a line to set the SF_Exported flag in COFFObjectFile - the JIT needs this flag to distinguish exported symbols from non-exported ones. In the process of trying to write a test case for that, a couple of questions came up: (1) Previously COFF wasn't setting either SF_Exported or SF_Hidden. What is the linker using to build the export table for

On Fri, Oct 19, 2012 at 2:55 AM, r4start <r4start at gmail.com> wrote: > Hi all. > > While compiling next code > @A = weak unnamed_addr constant { i32, i32, i32 } { i32 0, i32 0, i32 0 }, > section ".data" > was discovered that llc ignores weak linkage if we emit it in COFF object. > Attached patch solves this problem, please review. > > I found some

Hi all. While compiling next code @A = weak unnamed_addr constant { i32, i32, i32 } { i32 0, i32 0, i32 0 }, section ".data" was discovered that llc ignores weak linkage if we emit it in COFF object. Attached patch solves this problem, please review. I found some similar tests in test/Objects/Inputs. Should I do something like trivial.ll checking or there is a better way to check

Hi Daniel, Nice to meet you. My understanding of the Microsoft #pragma comment(lib, ...) semantics is that each specified library will be converted into a directive that starts with "/DEFAULTLIB" in the COFF .drectve section. To demonstrate, the following patch produces directives that work with Visual Studio 2010 using the now-deprecated dependent library feature (commits r168779 and r168694). /* beginning of patch */ Index: /home/ygao/LLVM/llvm/lib/Target/X86/X86AsmPrinter.cpp ==============================...

Hi all, We plan to add some auto-linking support for Mach-O, and need a scheme for encoding this information in the LLVM IR. We would like the same scheme to be able to support Microsoft's #pragma comment(lib,...) and #pragma comment(library, ...) features eventually. The current proposal is as follows: -- #1. Extend module-level metadata flags (llvm.module.flags) to support two new

Hi David, Thanks for the feedback! I've reverted r258665 until I understand this better. > The linker considers three sources: > - EXPORTS directives in a .def file given to the linker > - The linker's /EXPORT option > - Object files carry a special section, .drectve, which contains additional flags that the linker takes under consideration. __declspec(dllexport) is typically implemented by adding a /EXPORT entry for a particular symbol in there (e.g. /EXPORT:_foo). Ok. > > (2) Is there any situation where 'SF_Exported' isn't just the inver...

...14C machine (x86) 3 number of sections 50853E78 time date stamp Mon Oct 22 16:39:20 2012 123 file pointer to symbol table 9 number of symbols 0 size of optional header 0 characteristics SECTION HEADER #1 .drectve name 0 physical address 0 virtual address 2F size of raw data 8C file pointer to raw data (0000008C to 000000BA) 0 file pointer to relocation table 0 file pointer to line numbers 0 number of relocations 0 number of line numbers 100A00 flags...

...er, ...) will map naturally to this > format. How #pragma comment(lib, ...) gets handled will probably depend on > the details of how this is encoded in the COFF object files, which I am not > yet familiar with. On COFF #pragma comment(lib, ...) just gets turned into a linker flag in the .drectve section. > > #3. We make no attempt to encode ordering information amongst the options, > which limits the utility for linking against static libraries. The current > expectation is that this feature be used for system libraries where the > order of the options is not important. A s...

...If an export is a form of /export:foo=dllname.bar, that means // that foo should be exported as an alias to bar in the DLL. // ForwardTo is set to "dllname.bar" part. Usually empty. StringRef ForwardTo; StringChunk *ForwardChunk = nullptr; // True if this /export option was in .drectves section. bool Directives = false; StringRef SymbolName; StringRef ExportName; // Name in DLL bool operator==(const Export &E) { return (Name == E.Name && ExtName == E.ExtName && Ordinal == E.Ordinal && Noname == E.Noname && D...

...ectly written in asm output. For example, when declaring a function like this: __declspec(dllexport) int __cdecl exportFunc1(int c); ASM output is: .def _exportFunc1; .scl 2; .type 32; .endef .text .globl _exportFunc1 .align 16, 0x90 _exportFunc1: movl 4(%esp), %eax ret .section .drectve,"r" .ascii " -export:_exportFunc1" GNU assembler fails with the message that it can't find the symbol _exportFunc1. When removing the leading underscores ("-export:exportFunc1") GAS is happy. This is also how GCC for mingw behaves. I can write a small patch...

...Tools package and set PATH environment variable for all. Then when I ran "Rcmd SHLIB combo.f" I got as far as: Rcmd SHLIB combo.f ar cr combo.a *.o ranlib combo.a gcc --shared -s -o combo.dll combo.def omo.a -LC:/PROGRA~1/R/rw1070/src/gnuwin32 -lg2c -lR Warning: .drectve '%.*s' unrecognized So I tried to reinstall R to C:\rw1070, instead of C:\program files, because I read that spaces in file names may cause errors. Now I don't even get that far. Now it reads: g77 -02 -Wall -c combo.f combo.o application has requested runtime to terminate i...

...gnored) > Well, the content is only in the object files. The final linked binary does not contain it (which is why Im abusing the SHT_NOTE). Do you mean does the linker ignore it? Well, if the linker doesn't support the feature, it would. In PE/COFF, it is encoded as a special section (.drectve). In fact, GNU ld doesn't have as complete of an implementation as lld/link and does ignore a bunch of options. MachO has a special load command (LC_LINKOPT) that encodes this. But, in both cases, it requires the linker to interpret it, and if it does not, then the same behavior would be obs...

...on_alignment__) : { KEEP(*(.xdata*)) } .bss BLOCK(__section_alignment__) : { __bss_start__ = . ; *(.bss) *(COMMON) __bss_end__ = . ; } .edata BLOCK(__section_alignment__) : { *(.edata) } /DISCARD/ : { *(.debug$S) *(.debug$T) *(.debug$F) *(.drectve) *(.note.GNU-stack) *(.gnu.lto_*) } .idata BLOCK(__section_alignment__) : { /* This cannot currently be handled with grouped sections. See pep.em:sort_sections. */ KEEP (SORT(*)(.idata$2)) KEEP (SORT(*)(.idata$3)) /* These zeroes mark the end of the import list....

On Tue, Jan 20, 2015 at 5:35 PM, Nick Kledzik <kledzik at apple.com> wrote: > On Jan 19, 2015, at 6:33 PM, Chandler Carruth <chandlerc at google.com> > wrote: > > > I wanted to go through and map out the layering of LLD's libraries today > and found that it's essentially impossible. I think some serious cleanup is > needed here. > > > >