search for: environmenttype

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 th...

...ateMachOStreamer(Ctx, MAB, _OS, _Emitter, RelaxAll); if (TheTriple.isOSWindows()) return createWinCOFFStreamer(Ctx, MAB, *_Emitter, _OS, RelaxAll); return createELFStreamer(Ctx, MAB, _OS, _Emitter, RelaxAll, NoExecStack); } --------------- 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). Eli From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On B...

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

...or whether it should be a new triple component. Looking at the uses in the LLVM code base, it seems that the environment element has been used specifically to enable generation of MachO objects on non-Darwin OSes. I see that clang recognizes “iphoneos” as a value (though it’s not in the Triple::EnvironmentType enum), and it’s not clear to me what it uses it for. Beyond that, the environment seems to be used to influence ABI selection, which would seem to have some degree of overlap with object format selection while being essentially different. > > > > In other words, environment seems t...

...or whether it should be a new triple component. Looking at the uses in the LLVM code base, it seems that the environment element has been used specifically to enable generation of MachO objects on non-Darwin OSes. I see that clang recognizes “iphoneos” as a value (though it’s not in the Triple::EnvironmentType enum), and it’s not clear to me what it uses it for. Beyond that, the environment seems to be used to influence ABI selection, which would seem to have some degree of overlap with object format selection while being essentially different. In other words, environment seems to be a bit of a catch-a...

...d be a new triple component. Looking at the uses in the > LLVM code base, it seems that the environment element has been used > specifically to enable generation of MachO objects on non-Darwin OSes. I > see that clang recognizes “iphoneos” as a value (though it’s not in the > Triple::EnvironmentType enum), and it’s not clear to me what it uses it > for. Beyond that, the environment seems to be used to influence ABI > selection, which would seem to have some degree of overlap with object > format selection while being essentially different.**** > > ** ** > > In other words...

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,

...ime system for GHC Haskell, the stack pointer register is not the same as the one defined by the operating system ABI, and it's difficult for GHC to change that. Following the example of CoreCLR in LLVM, it seems one way to remedy this situation is to define a new ABI (i.e., a new llvm::Triple::EnvironmentType ) and modify the code generator as-needed to respect to our ABI, through our own definition of an MCAsmInfo class for each architecture, etc. My question is: how feasible is it to extend MCAsmInfo with an override for the stack pointer register and have that fact be respected by the code generator...

...or whether it should be a new triple component. Looking at the uses in the LLVM code base, it seems that the environment element has been used specifically to enable generation of MachO objects on non-Darwin OSes. I see that clang recognizes “iphoneos” as a value (though it’s not in the Triple::EnvironmentType enum), and it’s not clear to me what it uses it for. Beyond that, the environment seems to be used to influence ABI selection, which would seem to have some degree of overlap with object format selection while being essentially different. In other words, environment seems to be a bit of a catch-a...

...or whether it should be a new triple component. Looking at the uses in the LLVM code base, it seems that the environment element has been used specifically to enable generation of MachO objects on non-Darwin OSes. I see that clang recognizes “iphoneos” as a value (though it’s not in the Triple::EnvironmentType enum), and it’s not clear to me what it uses it for. Beyond that, the environment seems to be used to influence ABI selection, which would seem to have some degree of overlap with object format selection while being essentially different. In other words, environment seems to be a bit of a catch-a...

...or whether it should be a new triple component. Looking at the uses in the LLVM code base, it seems that the environment element has been used specifically to enable generation of MachO objects on non-Darwin OSes. I see that clang recognizes “iphoneos” as a value (though it’s not in the Triple::EnvironmentType enum), and it’s not clear to me what it uses it for. Beyond that, the environment seems to be used to influence ABI selection, which would seem to have some degree of overlap with object format selection while being essentially different. > > In other words, environment seems to be a bit o...

...or whether it should be a new triple component. Looking at the uses in the LLVM code base, it seems that the environment element has been used specifically to enable generation of MachO objects on non-Darwin OSes. I see that clang recognizes “iphoneos” as a value (though it’s not in the Triple::EnvironmentType enum), and it’s not clear to me what it uses it for. Beyond that, the environment seems to be used to influence ABI selection, which would seem to have some degree of overlap with object format selection while being essentially different. >> >> In other words, environment seems to be...

...t’s currently done in trunk (some changes required for x32 are already there) * Michael Liao work done ~2 years ago and available here: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20120604/058450.html What’s currently in trunk: * Triplet x86_64-*-linux-gnux32 (command line support, EnvironmentType enum to differentiate x32 from x86_64 by getTriple().getEnvironment() == llvm::Triple::GNUX32) https://github.com/llvm-mirror/llvm/commit/9dd2a3b1f2c253e20262535bb89b1ab6cc680ece * ILP32/LP64 differentiation for TargetMachine https://github.com/llvm-mirror/llvm/commit/a5597f0eaf1f93c6d0bc641a0cc54e...

On Wed, Jul 25, 2012 at 12:24 AM, Kaylor, Andrew <andrew.kaylor at intel.com>wrote: > > -------------------------------**** > > ELF Support on Windows**** > > -------------------------------**** > > **** > > There are various reasons that it would be nice to be able to support > generation of ELF objects on Windows through the MCJIT interface, one of >

...or whether it should be a new triple component. Looking at the uses in the LLVM code base, it seems that the environment element has been used specifically to enable generation of MachO objects on non-Darwin OSes. I see that clang recognizes “iphoneos” as a value (though it’s not in the Triple::EnvironmentType enum), and it’s not clear to me what it uses it for. Beyond that, the environment seems to be used to influence ABI selection, which would seem to have some degree of overlap with object format selection while being essentially different. In other words, environment seems to be a bit of a catch-a...

> > The Triple object will remain unchanged. > > The Tuple will be the API to handle getting/setting parameters > depending on the Triple, compiler flags, attributes, etc. > > This part doesn't seem obvious from the direction the patches are going. > There will be no string representation of all options, as that would > be impossible, or at least, highly

Following up and expanding on an earlier conversation, I'd like to discuss making several non-trivial changes to the MCJIT engine and related objects. There may be some interdependencies between these changes, but I think that they can be logically grouped as follows: * Lazy module compilation * Enhance the JIT memory manager interface to enable section-based memory protection * Clean up