similar to: AllocateTarget for ELF objects on Darwin

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

On 2018-12-08, at 2:27 PM, Ken Cunningham wrote: > And then we should be in business, and all systems will have thread_local . All that being sorted out, we now have libc++ 7.0.0 and libc++abi built and being used with emulated-tls support on darwin < 11 now. Thanks! The last bit of this I plan to sort out would be how to tweak the following patch so that __cxa_thread_atexit would be

Please excuse hobbiest-level question. Darwin 11+ enables thread_local variables using system-level supports. I have an interest in enabling TLS on darwin < 11 using emulated-tls. This can be enabled with a few modest patches: ========================== --- a/include/llvm/ADT/Triple.h.orig 2018-10-02 17:38:10.000000000 -0700 +++ b/include/llvm/ADT/Triple.h 2018-10-02 17:38:58.000000000

Attached is a working patch set for llvm to be able to emit arm64 (currently as triple aarch64-apple-ios) mach-o object files, in case someone is interested. I'm not sure if the llvm maintainers want the patch given the previous message that there's going to be an official patch set from apple to support this, but here is mine. What works (tested on an iPhone 5S): * objc strings,

On Thu, Jul 28, 2016 at 6:13 PM, Ramkumar Ramachandra via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > We were just debugging a sporadic crash the other day, when we noticed > that RIP-relative addressing was being used in a JumpTable, even when > code and data were well over 4G apart. This is confusing, because we > picked CodeModel::Large, and expected this to

Hi, We were just debugging a sporadic crash the other day, when we noticed that RIP-relative addressing was being used in a JumpTable, even when code and data were well over 4G apart. This is confusing, because we picked CodeModel::Large, and expected this to be taken care of. Isn't that what gcc would do given a Large CodeModel? The default Relocation Model, Reloc::Default, folds into

Eli Friedman wrote: > On Thu, Jul 28, 2016 at 6:13 PM, Ramkumar Ramachandra via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> We were just debugging a sporadic crash the other day, when we noticed >> that RIP-relative addressing was being used in a JumpTable, even when >> code and data were well over 4G apart. This is confusing, because we >> picked

On Fri, Jul 29, 2016 at 9:57 AM, Ramkumar Ramachandra <artagnon at gmail.com> wrote: > Eli Friedman wrote: > > On Thu, Jul 28, 2016 at 6:13 PM, Ramkumar Ramachandra via llvm-dev > > <llvm-dev at lists.llvm.org> wrote: > >> We were just debugging a sporadic crash the other day, when we noticed > >> that RIP-relative addressing was being used in a

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"

On Jul 23, 2012, at 1:52 PM, salvatore benedetto <salvatore.benedetto at gmail.com> wrote: > On Mon, Jul 23, 2012 at 8:14 PM, Renato Golin <rengolin at systemcall.org> wrote: >> On 23 July 2012 17:03, Chris Cadwallader <ccadwallader at arxan.com> wrote: >>> On Darwin, if -march is armv7 clang's driver will assume you want thumb2 unless you also give it

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

Kostya Serebryany <kcc at google.com> writes: > Justin, > Calling appendToUsed has horrible complexity and if we call it in > every function clang consumes tons of memory (6Gb when compiling one > of the clang's source files). This killed my machine today :) > > The solution is to call appendToUsed once per module, instead of once > per function. Oh right,

[+llvmdev, -llvm-dev] (Oopsies, llvmdev doesn't have a hyphen in it like all the others do) On 6/17/14, 10:45 AM, Jonathan Roelofs wrote: > [+llvm-dev, cfe-dev] > > Was "Re: [PATCH] ARM: allow inline atomics on Cortex M" > > On 6/17/14, 10:42 AM, Jonathan Roelofs wrote: >> >> >> On 6/17/14, 9:35 AM, Renato Golin wrote: >>> On 17 June 2014

Thanks Tom for your help, it as indeed very easy to make the link with the linker (not sick joke). Unfortunately, clang generates object files for target x86_64, even though I try --target --triple, --arch, ... What is the trick to tell him which target to use ? -- Fred ps: not looked yet at inline assembly 2015-07-09 18:40 GMT+02:00 Tom Stellard <tom at stellard.net>: > On Thu, Jul

I have @_rtti_a_a = linkonce_odr constant in two files that end up as coff object files. Shoudln't the linkonce_odr prevent duplicate symbol: __rtti_a_a \consoleapplication149.o and __rtti_a_a island.lib(island.o) from happening in LLD? If not what alternative can I use? THis is used for template like generics, so having duplicate functions and globals is going to happen a lot) (Side

On 2018-12-08 19:10, Ken Cunningham via llvm-dev wrote: > So putting it into libc++abi.dylib might indeed be the only workable method, assuming each executable would get it's own copy in memory and they wouldn't all collide together. Can ibc++abi link with libclang_rt to resolve the symbol? -- /Jacob Carlborg

For my Smart 2200, a charged battery string is anywhere between 25.6 and 26.8 volts. I'm seeing nut report 13.0 volts, which seems suspicious. Even if the UPS were reporting half of the actual battery voltage to keep protocol compatibility with models having a 12V battery system, the value of exactly 13.0 seems unlikely. According to the page at

Hi all, the backend data layout string is generated in X86TargetMachine.cpp. As far as I understand, however, that is not the only place where the target description string is generted. Where does the expected target description string come from? Thanks! -- ---------------- Barbora Murinová The University of Edinburgh SK: +421905718390 UK: +447477833795 -------------- next part --------------

Hi, I try to build llvm-trunk with Cmake (gcc-5.3.0 is necessary for CUDA) on my "SUSE Linux Enterprise Server 12.2 (x86_64)". svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm cd llvm/tools svn co http://llvm.org/svn/llvm-project/cfe/trunk clang svn co http://llvm.org/svn/llvm-project/polly/trunk polly cd clang/tools svn co

-march for clang and -march for llc do different things unfortunately. -march for clang at least on x86 is the same as -mcpu in llc. Which is an artifact of gcc compatibility. ~Craig On Sat, Mar 23, 2019 at 1:40 PM Doerfert, Johannes via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Oh, my bad. > > > Idk why llc seems to know that architecture but clang does not. > >