similar to: A "Cross-Platform Runtime Library API" in LLVM IR

> On May 22, 2016, at 10:31 AM, Lorenzo Laneve via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > My idea is an API where anyone can build a Runtime Library for any backend, including a set of functions people can inline/rename creating functions the frontend can include in the IR. > > For example implementing a cross-platform runtime function that allocates memory

I know, that's the problem. We can assume all of the system calls as runtime functions: such as I/O, allocations etc. and create a set of function implemented for all the architectures. For example, let's think about the mem allocation again: we can provide a primitive function with the same name for all archs (e.g. __alloc() ) and then people can include this function __alloc() in their

On 22 May 2016, at 20:32, Lorenzo Laneve via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I know, that's the problem. > We can assume all of the system calls as runtime functions: such as I/O, allocations etc. and create a set of function implemented for all the architectures. > For example, let's think about the mem allocation again: we can provide a primitive

So, the backend should implement "__alloc" that does the same as "malloc" - or something subtly different from "malloc" - and on a Windows machine, how is it different from "HeapAlloc"? And "__write" that is same as UNIX "write", but different from "WriteFile" in Windows? And HOW do you expect the backend to implement these? By

On 23 May 2016, at 12:00, Lorenzo Laneve <lore97drk at icloud.com> wrote: > > This is the point, No, you are still failing to make a point. > High-level OO languages don't use malloc(), they use something else. That’s not entirely true. They need to get the memory that they provide to programs from somewhere. They may provide their own pool allocators, but they will often

I'm not talking about a new library instead of the libc, I'm talking about letting people create a library optimized for a specific frontend, regardless of the target. > On May 23, 2016, at 1:06 PM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote: > >> On 23 May 2016, at 12:00, Lorenzo Laneve <lore97drk at icloud.com> wrote: >> >> This is the

I know but maybe malloc() is a bit higher level than a hypothetical __alloc(), which may be lower-level and then faster. And malloc() is contained in the libc as Matthias said and so maybe a program using malloc() even for a non-C language linking against the crt is needed. I'm just assuming that the functions we use in C such as malloc() are quite high-level interfaces and that there might

On 23 May 2016, at 10:13, Lorenzo Laneve <lore97drk at icloud.com> wrote: > > I know but maybe malloc() is a bit higher level than a hypothetical __alloc(), which may be lower-level and then faster. How? > And malloc() is contained in the libc as Matthias said and so maybe a program using malloc() even for a non-C language linking against the crt is needed. On many *NIX

This is the point, High-level OO languages don't use malloc(), they use something else. My idea was a C API with implementations of functions: For example Assuming I need to implement a function which allocates a new object. The API provides a really basic allocator function I can use to implement the complete function the high-level language needs. void *__newobject(int class_size) { void

On 23 May 2016, at 12:16, Lorenzo Laneve <lore97drk at icloud.com> wrote: > > I'm not talking about a new library instead of the libc, I'm talking about letting people create a library optimized for a specific frontend, regardless of the target. It sounded as if you were talking about a library that sits underneath such a thing. Lots of languages have their own runtime

You guys are saying that the library which defines the runtime library is written in C for many languages. The problem is that such functions are in the libc and so the object files have to be linked against the **entire** libc. Sorry if I'm wrong but isn't it a little inefficient or hard to handle? With "hard to handle" I mean the entry point: if I use C's I/O operations,

At least for Linux/Unix, there's very little you can actually achieve without at least some of the libc linked into your own system. Unless you actually write your own system call interface functions - which is dependent on the processor architecture (using `int X` [or `syscall`] in x86, perhaps `trap Y` in 68K, `swi` on ARM, etc) - values for X may vary depending on OS too, and ABI (different

Actually my idea was not to provide the same library for all languages, but it was to provide an API for creating a library that better fits the needs of a specific language. If you tell me that relying on the C runtime is the best way to make a runtime library and there are really few disadvantages, then ok. I also have to say that creating a runtime independent from the C runtime might make

> > FWIW, I build baremetal newlib for arm-eabi using clang, and it works. I >> had to patch a few of the __attribute__((naked)) functions because they >> were using pre-UAL asm syntax, but for the most part it "just works". >> > I build the baremetal newlib using arm-none-eabi-gcc as well, but after linking with the hello world program, it failed to run on

On Wed, Aug 02, 2017 at 05:48:20PM -0600, Jonathan Roelofs wrote: > I strongly recommend against using the host's headers when cross compiling. > You need to either find or build an arm-none-eabi sysroot, and use the > --sysroot= flag. > > > Jon OK, that's a start. I found https://www.llvm.org/docs/HowToCrossCompileLLVM.html. Is it enough for --sysroot? In case it is,

On Thu, Aug 03, 2017 at 08:22:24AM -0600, Jonathan Roelofs wrote: > IIUC, you don't want to cross compile llvm itself (which is what those > instructions are for), but instead you want to *use* llvm to cross compile > things. > > To build your sysroot, you'll need to cross-build: > > 1) A libc. Good choices for that for baremetal are: newlib or musl. > 2)

So we come back to my earlier comment: can you produce a one-file, < 100 lines that reproduce the issue? -- Mehdi > On Mar 24, 2016, at 10:16 AM, Lorenzo Laneve <lore97drk at icloud.com> wrote: > > Those lines of code are in a function that is called before calling the moduleToObjectFile() function > > On Mar 24, 2016, at 6:07 PM, Mehdi Amini <mehdi.amini at

You may want to try adding this code (copy/pasted from llc.cpp): // Initialize targets first, so that --version shows registered targets. InitializeAllTargets(); InitializeAllTargetMCs(); InitializeAllAsmPrinters(); InitializeAllAsmParsers(); // Initialize codegen and IR passes used by llc so that the -print-after, // -print-before, and -stop-after options work. PassRegistry

I’m using LLVM 3.8.0, and no, it’s the precompiled version That’s why it doesn’t give me enough info for debug > On 24 Mar 2016, at 1:53 AM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > This code path is not likely to crash usually. Did you build LLVM yourself? Which version are you using and can you reduce the test case to be "minimal" so that someone can

Passes all need to be initialized before they are added into a pass manager. Are you calling TargetLibraryInfoWrapperPass::initializePass anywhere? -Chris > On Mar 24, 2016, at 10:41 AM, Lorenzo Laneve via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > The problems happens because PMTopLevelManager::findAnalysisPassInfo(AnalysisID AID) returns nullptr in