similar to: [LLVMdev] Portable I/O

"Michael Ness" <mike at liquido2.com> writes: > I'm attempting to use file I/O across platforms from LLVM assembly > using the standard GNU C library: fprintf(), stdin/stdout, etc. > Ideally I'd like to simply provide a single bitcode file that could be > compiled on each platform, but because the internals of the I/O on > each platform is different, this is

"Michael Ness" <mike at liquido2.com> writes: > Some additional information about the setup may be of interest: > > I'm using CMake to generate the make files for MSYS. All appears to go well > until the tools are compiled. > > The undefined references seem to be coming from the libraries that were just > compiled: > >

Hello Óscar, The problem with that idea is that they require a pointer to a FILE structure. This file structure is included from stdio.h which has macros and conditional compilation all over the place. There are no constructors in these libraries to call and, as such, they are platform dependent. Is there any way to link in an external type definition to an opaque type? We'd need to

"Michael Ness" <mike at liquido2.com> writes: [snip] > I then used both of these builds to attempt to assemble and link my > project with llvm-g++: > > $ llvm-g++ out.s -o out.exe `llvm-config --ldflags --libs x86 core > system support` > > gave me the errors found in the attached file "errors_gcc.txt". And > > $ llvm-g++ out.s -o out.exe

"Michael Ness" <mike at liquido2.com> writes: > I decided to forget 2.5 and move on to 2.6 which built fine with CMake. > However, I continue to have problems with llvm-config when using the > following command: > > $ llvm-g++ out.s -o out `llvm-config --ldflags --libs core support system > x86` > > I consistently get undefined reference errors that are

Thanks Óscar, I decided to forget 2.5 and move on to 2.6 which built fine with CMake. However, I continue to have problems with llvm-config when using the following command: $ llvm-g++ out.s -o out `llvm-config --ldflags --libs core support system x86` I consistently get undefined reference errors that are from libraries that should've been linked already. The errors change depending

Some additional information about the setup may be of interest: I'm using CMake to generate the make files for MSYS. All appears to go well until the tools are compiled. The undefined references seem to be coming from the libraries that were just compiled: ../../lib/libLLVMBitReader.a(BitcodeReader.cpp.obj):fake:(.rdata$linkonce_ZTVN4llvm8ConstantE+0x10): undefined reference to

-------------------------------------------------- From: "Óscar Fuentes" <ofv at wanadoo.es> Sent: Friday, December 11, 2009 4:32 PM To: <llvmdev at cs.uiuc.edu> Subject: Re: [LLVMdev] Rebuilding LLVM libraries with LLVM-GCC on Windows > > You are working with an assembler file. Why? Here is the build process I'm using for my project: I have a program written in

Ok, more recent developments follow. I updated my MSYS and MinGW install to use binutils 2.20 and gcc 4.4.0. With this I was able to build LLVM 2.6 with the following CMake configuration: cmake -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_PIC=NO -DLLVM_ENABLE_THREADS=NO -G "MSYS Makefiles" ~/llvm-2.6-src I also downloaded the llvm-gcc 4.2 binaries from llvm.org and used them to

Hello again, In order to avoid the set jump/long jump dependency of DLLs built under Visual C++, we're trying to build the libraries and tools under LLVM-GCC so it will use DWARF exception handling instead of SJ/LJ. The problem we're running into is that the libraries that we just finished creating cannot be found later in the build process when OPT tries to build. My partner has MinGW

Óscar Fuentes <ofv at wanadoo.es> writes: >> git-svn often doesn't work, especially if the other side also needs >> git-svn. > > The git mirror would be read-only, so if you want to contribute changes > to LLVM using git you need git-svn anyways. I pull down changes from upstream much more frequently than I send changes up. To send changes up, diff+patch+svn,

Duncan Sands <baldrick at free.fr> writes: >> But you put me on the right track. The problem is that the class is >> returned on the stack. Correction: The class is returned on the FP stack: >> 0x6e08b5b5 <_ZN3Foo6GetFooEv+17>: fldl -0x8(%ebp) >> 0x6e08b5b8 <_ZN3Foo6GetFooEv+20>: leave >> 0x6e08b5b9 <_ZN3Foo6GetFooEv+21>:

Thanks everyone, a set of wrapper routines it will be then. Dustin, are the routines you wrote open source or do you know if there is already a project that provides such a portable interface to libc for LLVM? If not, I'll write my own routines, but if there is a way to adopt a common standard or avoid reinventing the wheel I'm all for it. Mike

Jean-Daniel Dupas <devlists at shadowlab.org> writes: > Le 29 janv. 2011 à 09:33, Mark Lacey a écrit : > >> I know this comes up periodically, but it looks like it has been a few months since there was any posting indicating that having an official git mirror for LLVM, et al. was still in the works. >> >> I am wondering if there is a timeline or resources lined up

greened at obbligato.org (David A. Greene) writes: > Jean-Daniel Dupas <devlists at shadowlab.org> writes: > >> Le 29 janv. 2011 à 09:33, Mark Lacey a écrit : >> >>> I know this comes up periodically, but it looks like it has been a >>> few months since there was any posting indicating that having an >>> official git mirror for LLVM, et al. was

Óscar Fuentes <ofv at wanadoo.es> writes: > BTW, -fpcc-struct-return solves the case that motivated this thread. -fpcc-struct-return is an ABI change, hence it requires "compiling the world". Not acceptable. I'll be interested on hearing ideas about how to determine how a function returns a small struct, without knowing the internals of the struct. -- Oscar

On 02/12/2010 09:51 AM, Chris Lattner wrote: > I think that the point is that you can define your own standard runtime interfaces: > > void *myopen(const char*path) { > return fopen(path, ...); > } Maybe my experience hand-coding LLVM will actually be of some help. What I did for this case is what I think Chris is suggesting--I have a .c file with functions that return

Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://westfish.xiph.org/pipermail/vorbis-dev/attachments/20040618/e7bee431/attachment.pgp

Take a look at llvm-gcc. Look for HandleAggregateShadowArgument. Evan On Mar 26, 2008, at 10:31 AM, Óscar Fuentes wrote: > Óscar Fuentes <ofv at wanadoo.es> writes: > >> BTW, -fpcc-struct-return solves the case that motivated this thread. > > -fpcc-struct-return is an ABI change, hence it requires "compiling the > world". Not acceptable. > > I'll

Eli Friedman <eli.friedman at gmail.com> writes: > On Wed, Aug 26, 2009 at 1:10 AM, Óscar Fuentes<ofv at wanadoo.es> wrote: >> While compiling some sources, translating from my compiler's IR to LLVM >> using the C++ API requires 2.5 seconds. If the resulting LLVM module is >> dumped as LLVM assembler, the file is 240,000 lines long. Generating >> LLVM