similar to: [LLVMdev] lld coding style

Displaying 20 results from an estimated 20000 matches similar to: "[LLVMdev] lld coding style"

2014 Oct 06
2
[LLVMdev] lld coding style
On Oct 5, 2014, at 9:37 AM, Renato Golin <renato.golin at linaro.org> wrote: > On 5 October 2014 07:19, Saleem Abdulrasool <compnerd at compnerd.org> wrote: >> So with that in mind, I would like to ask, would it be possible to consider >> switching to LLVM style for lld? > > We don't usually enforce code styles on side projects because it > doesn't
2014 Oct 05
6
[LLVMdev] lld coding style
On Sun, Oct 5, 2014 at 9:37 AM, Renato Golin <renato.golin at linaro.org> wrote: > On 5 October 2014 07:19, Saleem Abdulrasool <compnerd at compnerd.org> wrote: > > So with that in mind, I would like to ask, would it be possible to > consider > > switching to LLVM style for lld? > > We don't usually enforce code styles on side projects because it >
2014 Jun 23
4
[LLVMdev] Support for Windows Phone 8.1
On Wed, Jun 18, 2014 at 10:25 AM, Saleem Abdulrasool <compnerd at compnerd.org> wrote: > On Wed, Jun 18, 2014 at 9:09 AM, Damanjit Singh <dsingh at adobe.com> wrote: > >> Hi Saleem, >> >> Though a simple app works great I am facing few issues trying to link a >> slightly complex object file, generated via LLVM, with some libs generated >> via
2018 Jan 04
1
Linker Option support for ELF
On Wed, Jan 3, 2018 at 8:08 PM, Sean Silva <chisophugis at gmail.com> wrote: > > > On Wed, Jan 3, 2018 at 4:02 PM, Saleem Abdulrasool <compnerd at compnerd.org> > wrote: > >> Hello all, >> >> There was some interest from a number of a few people about adding >> support for embedded linker options to ELF. This would be an extension >> that
2019 Mar 27
4
RFC: ELF Autolinking
On Wed, Mar 27, 2019 at 2:03 AM Saleem Abdulrasool <compnerd at compnerd.org> wrote: > On Tue, Mar 26, 2019 at 11:13 AM bd1976 llvm <bd1976llvm at gmail.com> wrote: > >> Thanks Saleem/James. >> >> On Tue, Mar 26, 2019 at 5:15 AM Saleem Abdulrasool <compnerd at compnerd.org> >> wrote: >> >>> Yes, I don't think that supporting all
2015 Apr 24
3
[LLVMdev] unwind move *NOW*
Greetings, As previously mentioned, the unwind contents are going to be moved today. Im working on this now. If you could please hold off any commits to the Unwind part of things, it would be greatly appreciated. See you on the new layout! -- Saleem Abdulrasool compnerd (at) compnerd (dot) org -------------- next part -------------- An HTML attachment was scrubbed... URL:
2015 Jan 31
2
[LLVMdev] unwind's permanent residence
On Fri, Jan 30, 2015 at 4:12 PM, Saleem Abdulrasool <compnerd at compnerd.org> wrote: > On Fri, Jan 30, 2015 at 3:35 PM, Dan Albert <danalbert at google.com> wrote: > >> Shouldn't it just use the default unwinder for the given platform? >> > > Sure, but what is the default unwinder for a given platform? > > Lets go with Linux. I have two different
2015 Jan 31
0
[LLVMdev] unwind's permanent residence
On Fri, Jan 30, 2015 at 4:15 PM, Dan Albert <danalbert at google.com> wrote: > On Fri, Jan 30, 2015 at 4:12 PM, Saleem Abdulrasool <compnerd at compnerd.org > > wrote: > >> On Fri, Jan 30, 2015 at 3:35 PM, Dan Albert <danalbert at google.com> wrote: >> >>> Shouldn't it just use the default unwinder for the given platform? >>> >>
2018 Jan 04
0
Linker Option support for ELF
On Wed, Jan 3, 2018 at 4:02 PM, Saleem Abdulrasool <compnerd at compnerd.org> wrote: > Hello all, > > There was some interest from a number of a few people about adding support > for embedded linker options to ELF. This would be an extension that > requires linker support to actually work, but has significant prior art > with PE/COFF as well as MachO both having support
2014 Jun 18
2
[LLVMdev] Support for Windows Phone 8.1
Hi Saleem, Though a simple app works great I am facing few issues trying to link a slightly complex object file, generated via LLVM, with some libs generated via Visual Studio - 1. Seems IMAGE_SCN_MEM_16BIT is only written for the the first header in the COFF file, thus functions in other headers (if you are using function sections) don’t work. I was able to workaround this by forcing this entry
2019 Mar 26
2
RFC: ELF Autolinking
Thanks Saleem/James. On Tue, Mar 26, 2019 at 5:15 AM Saleem Abdulrasool <compnerd at compnerd.org> wrote: > Yes, I don't think that supporting all options is entirely possible. But, > there is certainly some allure to it, as it is a really powerful feature > (which you can tell from the behaviour of link and `.drectve` section). > The problem with all options is that
2014 Jun 08
2
[LLVMdev] Code generation support in llvm for windows phone
Thank you so much Saleem, The target is Windows phone 8.1 (ARM). I'll update the crash details tomorrow. One big problem is that I have to use a physical windows phone for execution. I wonder if it is possible to execute such "exes" using qemu. Regards, Kashyap On Sun, Jun 8, 2014 at 2:53 AM, Saleem Abdulrasool <compnerd at compnerd.org> wrote: > On Sat, Jun 7, 2014 at
2014 Sep 06
2
[LLVMdev] [Compiler-RT] [ARM] Where __aeabi_[il]div0 builtins should be implemented?
On Fri, Sep 5, 2014 at 11:32 AM, Jonathan Roelofs <jonathan at codesourcery.com > wrote: > Sergey, > > Not that it'll save you much hassle, but here's an implementation of > __aeabi_idiv0 and __aeabi_ldiv0 that I've been sitting on for a while. > > I vaguely remember compnerd suggesting that I don't commit them to > compiler_rt, but I don't remember
2018 Jan 04
8
Linker Option support for ELF
Hello all, There was some interest from a number of a few people about adding support for embedded linker options to ELF. This would be an extension that requires linker support to actually work, but has significant prior art with PE/COFF as well as MachO both having support for this. The desire here is to actually add support to LLVM to pass along the necessary information into the object
2015 Jan 30
2
[LLVMdev] unwind's permanent residence
On 30 Jan 2015 21:24, "Saleem Abdulrasool" <compnerd at compnerd.org> wrote: > The library is agnostic of the unwinder, the driver is who cares (as it needs to generate the linker invocation). I think that adding a flag to control that similar to -rtlib is probably what we may have to do then. What about the default unwinder for Compiler-RT? Should we assume our own?
2015 Feb 05
3
[LLVMdev] unwind's permanent residence
On Tue, Feb 3, 2015 at 4:07 AM, Renato Golin <renato.golin at linaro.org> wrote: > On 30 January 2015 at 20:43, Jonathan Roelofs <jonathan at codesourcery.com> > wrote: > > Last time we brought this up, there was only partial consensus, and then > > someone arbitrarily declared total consensus (without compelling > arguments > > in any particular direction)
2014 Jun 09
2
[LLVMdev] Support for Windows Phone 8.1
Thanks a lot Saleem, The issue is fixed and a simple app works fine now. -Daman On 08/06/14 12:57 pm, "Nick Lewycky" <nicholas at mxc.ca> wrote: >Damanjit Singh wrote: >> Thanks Saleem, Nick. >> >> I will try with the latest code and share the results. >> >> Though, just curious if I need to really use clang to generate the >> object file
2015 Apr 22
4
[LLVMdev] unwind's permanent residence
On Wed, Apr 22, 2015 at 5:12 PM, Renato Golin <renato.golin at linaro.org> wrote: > On 22 April 2015 at 03:40, Saleem Abdulrasool <compnerd at compnerd.org> wrote: >> So after a bit of a hiatus (sorry, other stuff has been eating up my free >> time), Id like to pick this up again. I think that its a matter of just >> copying the unwind sources into the right
2014 Sep 10
2
[LLVMdev] [Compiler-RT] [ARM] Where __aeabi_[il]div0 builtins should be implemented?
On Tue, Sep 9, 2014 at 1:37 AM, Renato Golin <renato.golin at linaro.org> wrote: > On 9 September 2014 02:18, Saleem Abdulrasool <compnerd at compnerd.org> > wrote: > > The current implementations actually return 0. Can you point out where > that > > doesn't hold please? > > With the current implementation... > > int foo(int a) { > return
2015 Jan 30
2
[LLVMdev] unwind's permanent residence
On Fri, Jan 30, 2015 at 3:10 PM, Saleem Abdulrasool <compnerd at compnerd.org> wrote: > On Fri, Jan 30, 2015 at 1:41 PM, Renato Golin <renato.golin at linaro.org> > wrote: > >> What about the default unwinder for Compiler-RT? Should we assume our >> own? Gcc's? Assuming nothing will break compilation, since the libraries >> won't be available...