similar to: SF_Exported vs SF_Hidden

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

Hi, I'm currently working my way through the tutorial with LLVM 3.9.1 on Windows (finished chapter 4) and stumbled over a few things which could be improved: - "LLVMContext" does not exist as a variable -> "TheContext" - Chapter 3: 5 times - Chapter 4: 1 time - Chapter 5: 4 times - Chapter 6: 2 times - Chapter 7: 2 times 3.4. Function Code

Hello all, I was able to create R packages under windows XP in the past using the dynamic NAG C library for windows XP (Mark 6). Recently, I changed computers and I am now using the static NAG C library for windows XP (Mark 7) to create a simple R package (called "test") which simply returns random numbers simulated using repetitive calls to a NAG C routine (uniform random

Hello, I'm working on a binary translator project that emits an .ll file. I'm trying to debug it in Visual Studio and would like to be able to step through and see my generated .ll file in the debugger. Does LLVM support debug information corresponding to an input .ll file? My hunch is "no, as it expects debug info to come from Clang." I assemble it using: llc -filetype=obj

Hi Gao, Thanks for the extra information... On Wed, Jan 16, 2013 at 1:14 PM, Yunzhong Gao <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

On Tue, Jan 20, 2015 at 6:06 PM, Rui Ueyama <ruiu at google.com> wrote: > On Tue, Jan 20, 2015 at 5:42 PM, Chandler Carruth <chandlerc at google.com> > wrote: > >> >> 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> >>>

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

I see that there is an auxsymbol per section symbol, and also on the yaml representation there is a checksum, selection and unused all of them I have no idea how to fill in, also this aux symbol might have some important information for me to patch on the other symbols. Can you find the part in llvm that it writes those? because at least for auxsymbol the yaml part of the code threats as a binary

Hi Larry, Thanks so much! This seems to do the trick. I would have spun my wheels for > a long time before discovering all of this, wow. No worries. :) I'll try to keep this in mind and make sure I address it in future Kaleidoscope tutorial chapters - these issues tripped me up the first time I encountered them too. Do I even want to know what additional chickens need to be sacrificed

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

I'm so close I can almost smell it :) I know how bad the code looks, I don't intend to submit this, but if you want to try it out its at: https://gist.github.com/santagada/544136b1ee143bf31653b1158ac6829e I'm seeing: lld-link.exe: error: duplicate symbol: "<redacted_unmangled>" (<redacted>) in <internal> and in <redacted_filename>.obj, looking at the

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

On Fri, Jan 19, 2018 at 1:02 PM Leonardo Santagada <santagada at gmail.com> wrote: > On Fri, Jan 19, 2018 at 9:44 PM, Zachary Turner <zturner at google.com> > wrote: > >> >> >> On Fri, Jan 19, 2018 at 12:29 PM Leonardo Santagada <santagada at gmail.com> >> wrote: >> >>> Hi, >>> >>> No I didn't, I used cl.exe

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

>> llvm::sys::DynamicLibrary::LoadLibraryPermanently(nullptr) This is one is a bit tricky and hard to find. I spent quiet some time digging into MC and ORC JIT execution engines trying to find what makes them work. The problem is that this trick (LoadLibraryPermanently) happens inside of EngineBuilder, despite that the functionality belongs to a JIT engine itself, not to the builder. I

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

You probably don't want to go down the same route that clang goes through to write the object file. If you think yaml2coff is convoluted, the way clang does it will just give you a headache. There are multiple abstractions involved to account for different object file formats (ELF, COFF, MachO) and output formats (Assembly, binary file). At least with yaml2coff It's true that yaml2coff

Any idea on how to create this new symbol there? I saw that there is a symbol pointing to each section, but didn't understand the format, and yaml2obj doesn't check it or do anything with the list. On Thu, Jan 25, 2018 at 6:56 PM, Leonardo Santagada <santagada at gmail.com> wrote: > YES, THANK YOU... I WAS THINKING THIS BUT COMPLETELY FORGOT. > > sorry for the caps... long

I haven't really dabbled in this part of the COFF format personally, so hopefully I'm not leading you astray :) But I checked the code for coff2yaml, and I see this: } else if (Symbol.isSectionDefinition()) { // This symbol represents a section definition. assert(Symbol.getNumberOfAuxSymbols() == 1 && "Expected a single aux symbol to

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