similar to: [LLVMdev] triples for baremetal

Eric, Attached are patches for llvm and clang that implement this. I've made 'none' a component that must be added explicitly (i.e. don't turn arm-eabi into arm--none-eabi, but rather turn it into arm--unknown-eabi) to try to reduce surprises. It also keeps the normalization logic a bit simpler than it would otherwise have to be. SPIR triples were one place where I was

Thanks for the clarifications, Bob! I’ve spent some time with the head of the llvm.org repo, and I now understand a lot better what Renato and Tim were talking about re. the architecture aliases. The patch to add v6l, therefore, seems simple enough. I haven’t been able to test it in my usual flow, because that involves the whole swift stack. I’m considering creating a program that links to

Hi Jonathan, This looks a bit odd. Any reason for the unknown->none conflating in this way? For most (all) of the ports unknown-elf works the same as none-elf. I'm also not sure if someone decided to have, arm-codesourcery-elf that this would still work with the patch. Thoughts? -eric On Tue, Jun 24, 2014 at 7:35 AM, Amara Emerson <amara.emerson at gmail.com> wrote: > Hi Jon,

On 6/23/14, 8:31 AM, David Chisnall wrote: > On 23 Jun 2014, at 15:13, Renato Golin <renato.golin at linaro.org> wrote: > >> The main issue with your patch is that it can change user expected >> behaviour, and I can't tell you what is the expected behaviour in >> Darwin or BSD. If people usually use "unknown" in triples, this will >> break their

Hi Jonathan, The main issue with your patch is that it can change user expected behaviour, and I can't tell you what is the expected behaviour in Darwin or BSD. If people usually use "unknown" in triples, this will break their builds. If not, this could break the build of someone who does. My advice is to create a "default" mechanism for the affected targets, something

> You assume triples make sense. That's the first mistake everyone does > when thinking about triples. :) I know they don't make sense in many corner cases, but I think discarding logic where it *does* exist is a mistake. > AFAIK, "ARMv7B" is only used by HighBank, which is no more. But that, > too, was "ARMv7A big endian". I believe it's what any

Dear LLVM developers, Hello, I'm trying to find a way of cross-compiling my c code against Baremetal Cortex-M device (so target triple will be arm-none-eabi) only using LLVM/Clang, and not using anything from GNU (ld or libc). I'm doing this to know which one of LLVM/clang and GCC produces smaller flash image size because saving flash is a big deal in our projects. 1) When I just follow

Hi, > Would it be OK to add "ELF" to Triple::EnvironmentType? It seems like a plausible choice since MachO is there. On the other hand, I'm not sure whether it makes sense to make it mutually exclusive with the other members of EnvironmentType (GNU, GNUEABI, EABI). EABI and GNUEABI imply ELF. GNU in practice does not need to imply ELF, but is used in the ARM world as "the

Hello, We're currently working on MC-JIT, focusing on runtime generation and loading of ELF object files, even on non-ELF platforms (i.e. Windows). However, we run into a problem with MC insisting to generate COFF objects on Windows, MachO on Macs and ELF only otherwise, based on the triple. Is there an existing method to generate ELF objects with MC on Windows, without modifying MC? Thanks

Ping, Apart from Anton's concerns (which I think are manageable) and Micah's support, I received no reply on this. Does there exist a way to tell MC to generate and ELF container for code on Windows? If not, I'm willing to submit a patch to fix this, but would like some opinions on the best direction to take here. The proposed "llvm::TargetSpec class"

Hello, I want to build LLVM/Compiler-rt for baremetal targets like Cortex-M3. By adopting CMake options from http://llvm.1065342.n5.nabble.com/llvm-dev-Compiling-for-baremetal-ARMv4-on-Ubuntu-Linux-tp124226p124500.html, I can only build "libclang_rt.builtins-x86_64.a" in lib/linux, but what I want to build is "libclang_rt.builtins.arm.a". My CMake options are: cmake -G Ninja

Hi, There are several places in compiler-rt which refer to __aeabi_idiv0. For example, in lib/builtins/arm/udivsi3.S: #ifdef __ARM_EABI__ b __aeabi_idiv0 #else JMP(lr) #endif At the same time there is no definition of it. It looks as if it was done intentionally so that third-party could provide custom handler for division by zero. IMHO It's not very consistent and looks odd as

Hi all In unittests/ADT/APIntTest.cpp I came across this test: // XFAIL this test on FreeBSD where the system gcc-4.2.1 seems to miscompile it. #if defined(__llvm__) || !defined(__FreeBSD__) TEST(APIntTest, i33_Count) { APInt i33minus2(33, static_cast<uint64_t>(-2), true); EXPECT_EQ(0u, i33minus2.countLeadingZeros()); EXPECT_EQ(32u, i33minus2.countLeadingOnes()); EXPECT_EQ(33u,

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,

> > 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 Jan 4, 2017, at 9:49 AM, Zachary Turner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > TL;DR - I want this. For the most part, +1 from me too. A few comments though. > > On Wed, Jan 4, 2017 at 6:11 AM Chandler Carruth via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > ## Matchers > > To start off, it

Should tablegen detect this as an error, or is it documented as a limitation somewhere that we've missed? In the tablegen-generated file AMDILGenIntrinsics.inc, we have a bunch of if statements comparing strings, many of which are dead, preventing correct recognition of some intrinsics in the their text form. I'm not quite sure what GET_FUNCTION_RECOGNIZER is used for, but if it's

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)

If the source being scanned has "llvm.AMDIL.barrier.global, it will match the first barrier test and return AMDIL_barrier, not AMDIL_barrier_global. On Nov 29, 2012, at 7:19 PM, Chris Lattner <clattner at apple.com> wrote: > Out of curiosity, what is wrong about that? It looks ok to me. > > -Chris > > On Nov 29, 2012, at 6:52 PM, "Relph, Richard"

Out of curiosity, what is wrong about that? It looks ok to me. -Chris On Nov 29, 2012, at 6:52 PM, "Relph, Richard" <Richard.Relph at amd.com> wrote: > Should tablegen detect this as an error, or is it documented as a limitation somewhere that we've missed? > > In the tablegen-generated file AMDILGenIntrinsics.inc, we have a bunch of if statements comparing