similar to: Add -fbinutils-version=

I'm seeing something similar. clang is using HOST_LINK_VERSION, obtained from ld64, as the default for -mlinker-version. This causes Darwin.cpp to add the arguments you are seeing, but not handled by lld. Perhaps -fuse-ld should be considered in addition to -mlinker-version when adding these arguments. As a workaround, you can try passing -mlinker-version. Looks like anything < 133

MachO support in lld is not really ready for real world usage. It was able to bootstrap itself a couple of years ago, but, it has not really been maintained or further developed since. I would recommend that you use ld64 if you are intending to build MachO binaries. > On Jan 7, 2018, at 9:57 AM, Don Hinton via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I'm seeing

We need to build with -mno-pic to disable all uses of GP, as well as use a custom linker script to avoid collisions between klibc.so's and the executable's segments. Signed-off-by: James Clarke <jrtc27 at jrtc27.com> --- usr/klibc/arch/ia64/MCONFIG | 3 + usr/klibc/arch/ia64/crt0.S | 4 - usr/klibc/arch/ia64/klibc.ld | 267 ++++++++++++++++++++++++++++++++++++++++++

Commit-ID: 8418552770110e9864ab24d60d8481fac58d3a65 Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=8418552770110e9864ab24d60d8481fac58d3a65 Author: James Clarke <jrtc27 at jrtc27.com> AuthorDate: Mon, 21 Jan 2019 21:26:57 +0000 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Mon, 21 Jan 2019 22:51:27 +0000 [klibc] ia64: Fix shared build We

ELF that MCJIT writes on x86_64 has relocations in it. Particularly, R_X86_64_PC32 relocations are used for the sections .gcc_except_table and .eh_frame related to exception processing. I am not sure where is general documentation on relocation types, including R_X86_64_PC32. Looks like it's nowhere to be found on the web. But 32-bit relocation can't be used in 64-bit code since it

On 07/08/2011 01:25 PM, Yuri wrote: > ELF that MCJIT writes on x86_64 has relocations in it. Particularly, > R_X86_64_PC32 relocations are used for the sections .gcc_except_table > and .eh_frame related to exception processing. > I am not sure where is general documentation on relocation types, > including R_X86_64_PC32. Looks like it's nowhere to be found on the web. > But

On 09/02/2011 05:58 PM, Duncan Sands wrote: > Hi Yiannis, > >> I have been using llvm 2.8 (i know ancient history!) for a backend that i was >> implementing. I have been trying to port my patches to latest llvm (svn build) >> lately but i have one problem as far as the Exception Handling mechanism is >> concerned. It seems that there are no Exception Tables generated

Hi Yiannis, >>> I have been using llvm 2.8 (i know ancient history!) for a backend that i was >>> implementing. I have been trying to port my patches to latest llvm (svn build) >>> lately but i have one problem as far as the Exception Handling mechanism is >>> concerned. It seems that there are no Exception Tables generated any more such >>> as the one

Hi, I am trying to compile LLVM for AARCH (VMA=42), here my cmake command: cmake -G "Ninja" -D SANITIZER_AARCH64_VMA=42 .. But I get the following warning: ------------------------------------------------------------------------------------------ CMake Warning: Manually-specified variables were not used by the project: SANITIZER_AARCH64_VMA

hi: maybe this should not be here! the test code: eh3.cpp int main() { try { throw 34; } catch (int) { } catch (char) { } catch (bool) { } } compile with g++ -S -dA eh3.cpp -o eh3.s the except table of the eh3.s 106 .section .gcc_except_table,"a", at progbits 107 .align 4 108 .LLSDA2: 109

> On Jan 6, 2018, at 4:33 PM, Sean Silva <chisophugis at gmail.com> wrote: > > > > On Jan 6, 2018 12:05 PM, "Saleem Abdulrasool via llvm-dev" <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> On Jan 5, 2018, at 4:35 PM, Cary Coutant <ccoutant at gmail.com <mailto:ccoutant at gmail.com>> wrote: >>

On Sun, May 11, 2014 at 8:19 AM, Stephan Tolksdorf <st at quanttec.com> wrote: > Hi, > > When clang/LLVM can't prove that a noexcept function only contains > non-throwing code, it seems to insert an explicit exception handler that > calls std::terminate. Why doesn't clang leave it to the eh personality > function to call std::terminate when an exception is thrown

2010/1/22 James Williams <junk at giantblob.com> > > > 2010/1/22 Duncan Sands <baldrick at free.fr> > > Hi James, >> >> >> I've been trying to get a minimal test function to work, which simply >>> invokes _Unwind_RaiseException with a single clean-up landing pad. However. >>> when I run it my personality function is not getting

2010/1/22 Duncan Sands <baldrick at free.fr> > Hi James, > > > I've been trying to get a minimal test function to work, which simply >> invokes _Unwind_RaiseException with a single clean-up landing pad. However. >> when I run it my personality function is not getting called - >> _Unwind_RaiseException simply returns apparently doing nothing. Looking at

Hi, I would like to get some feedback about the current status of the pre-RA machine scheduler bidirectional scheduling. I have tried enabling this on SystemZ, and found that it slightly increases spilling generally (in one benchmark with as much as 5%). Benchmarking do not indicate that bidirectional would be a win, either. Is this within the expected, or does it indicate something in the

Hi Yiannis, > I have been using llvm 2.8 (i know ancient history!) for a backend that i was > implementing. I have been trying to port my patches to latest llvm (svn build) > lately but i have one problem as far as the Exception Handling mechanism is > concerned. It seems that there are no Exception Tables generated any more such > as the one below: got some example bitcode for

Hey everybody! I have been using llvm 2.8 (i know ancient history!) for a backend that i was implementing. I have been trying to port my patches to latest llvm (svn build) lately but i have one problem as far as the Exception Handling mechanism is concerned. It seems that there are no Exception Tables generated any more such as the one below: .section .gcc_except_table,"a", at

Le 5 nov. 2013 à 19:00, Behan Webster <behanw at converseincode.com> a écrit : > On 11/05/13 09:26, Konstantin Tokarev wrote: >> >> 11.10.2013, 01:39, "Jakob Stoklund Olesen" <stoklund at 2pi.dk>: >>> On Oct 10, 2013, at 12:32 PM, Behan Webster <behanw at converseincode.com> wrote: >>> >>>> One of the issues the LLVMLinux

Hi, (Reposting the request to llvm-dev for better visibility) I had to revert a change today, due to test errors on some buildbots. The errors did seem to only happen on the ppc64be and aarch64 buildbots. I don't have access to a ppc64be setup to test on, but I've tried to build and run in a setup very similar to the one on the aarch64 buildbot, but I can't reproduce the errors

On 11/05/13 11:30, Jean-Daniel Dupas wrote: > > Le 5 nov. 2013 à 19:00, Behan Webster <behanw at converseincode.com > <mailto:behanw at converseincode.com>> a écrit : > >> On 11/05/13 09:26, Konstantin Tokarev wrote: >>> >>> 11.10.2013, 01:39, "Jakob Stoklund Olesen" <stoklund at 2pi.dk >>> <mailto:stoklund at 2pi.dk>>: