search for: gnuabin32

...::GNU for each of these ABI's in the form of the Triple::GNUEABI, Triple::GNUEABIHF, and Triple::GNUX32 values of the environment component of the triple and it's up to the frontend and/or API-user to pass the right thing to the backend. For MIPS, I'm defining Triple::GNUABI32, Triple::GNUABIN32, and Triple::GNUABI64. All three of these are supported by tools like binutils (by virtue of a wildcard match '*linux-gnu*') and of these three, Triple::GNUABI32 is not in general use, Triple::GNUABIN32 will be used by Debian if/when we do an N32 port, and Triple::GNUABI64 is currently used...

...y default for the N64 ABI without also enabling it for the N32 ABI because this information is not reflected in the triple and that's the only information MipsMCAsmInfo has. What would it take to pass more information to MipsMCAsmInfo? > For MIPS, I'm defining Triple::GNUABI32, Triple::GNUABIN32, and Triple::GNUABI64. All three of these are supported by tools like binutils (by virtue of a wildcard match '*linux-gnu*') and of these three, Triple::GNUABI32 is not in general use, Triple::GNUABIN32 will be used by Debian if/when we do an N32 port, and Triple::GNUABI64 is currently used...

https://bugzilla.mindrot.org/show_bug.cgi?id=2590 Bug ID: 2590 Summary: Seccomp filter for missing architectures Product: Portable OpenSSH Version: 7.2p1 Hardware: Other OS: Linux Status: NEW Keywords: patch Severity: enhancement Priority: P5 Component: sshd

...::GNU for each of these ABI's in the form of the Triple::GNUEABI, Triple::GNUEABIHF, and Triple::GNUX32 values of the environment component of the triple and it's up to the frontend and/or API-user to pass the right thing to the backend. For MIPS, I'm defining Triple::GNUABI32, Triple::GNUABIN32, and Triple::GNUABI64. All three of these are supported by tools like binutils (by virtue of a wildcard match '*linux-gnu*') and of these three, Triple::GNUABI32 is not in general use, Triple::GNUABIN32 will be used by Debian if/when we do an N32 port, and Triple::GNUABI64 is currently used...

...ked the information to do so. Since writing that, I have added a facility to ObjectFile that allows llvm-objdump to detect the feature bits from the Object header. The same technique can be used for other tools that handle ObjectFiles. > > For MIPS, I'm defining Triple::GNUABI32, Triple::GNUABIN32, and > > Triple::GNUABI64. All three of these are supported by tools like binutils (by > > virtue of a wildcard match '*linux-gnu*') and of these three, > > Triple::GNUABI32 is not in general use, Triple::GNUABIN32 will be used by > > Debian if/when we do an N32 port...

Hello, I'm trying to create a pure LLVM toolchain (that will not depend on GNU and produce GNU-free code too) on a musl based distribution. For now, I use gcc to bootstrap and build all LLVM components. I do it individually because I was running out of space and memory trying to build all using LLVM_ENABLE_PROJECTS. Also, I don't want to create a all-in-one package. Then, once

...re rarely O32) depending on the OS/distribution/toolchain/version. FWIW, back when I worked on it, we were generally moving towards the idea of canonical triples which contained the ABI and some lowering code on the user facing interfaces to disambiguate things like mips64-linux-gnu to mips64-linux-gnuabin32. *Just for completeness, the quirks I can remember off-hand were: - IEEE754 1985 and 2008 would successfully cross-link unless you used a flag indicating that it mattered. This was because we wanted to omit the 1985 standard from newer chips but there were many ecosystems using it due to historica...

...istribution/toolchain/version. FWIW, >> back when I worked on it, we were generally moving towards the idea of >> canonical triples which contained the ABI and some lowering code on the >> user facing interfaces to disambiguate things like mips64-linux-gnu to >> mips64-linux-gnuabin32. >> >> > To reply here a bit: > > I worry about target triple being used, but I think I do/did agree that > it's probably the best we can move to in the near term. My concern is that > we will have diverged from more "canonical" triples that are used in othe...

...lchain/version. FWIW, back when I worked on it, we were >>>> generally moving towards the idea of canonical triples which contained the >>>> ABI and some lowering code on the user facing interfaces to disambiguate >>>> things like mips64-linux-gnu to mips64-linux-gnuabin32. >>>> >>>> >>> To reply here a bit: >>> >>> I worry about target triple being used, but I think I do/did agree that >>> it's probably the best we can move to in the near term. My concern is that >>> we will have diverged from...

...re rarely O32) depending on the OS/distribution/toolchain/version. FWIW, back when I worked on it, we were generally moving towards the idea of canonical triples which contained the ABI and some lowering code on the user facing interfaces to disambiguate things like mips64-linux-gnu to mips64-linux-gnuabin32. > > > To reply here a bit: > > I worry about target triple being used, but I think I do/did agree that it's probably the best we can move to in the near term. My concern is that we will have diverged from more "canonical" triples that are used in other places just f...

...> OS/distribution/toolchain/version. FWIW, back when I worked on it, we were >> generally moving towards the idea of canonical triples which contained the >> ABI and some lowering code on the user facing interfaces to disambiguate >> things like mips64-linux-gnu to mips64-linux-gnuabin32. >> > >> > >> > To reply here a bit: >> > >> > I worry about target triple being used, but I think I do/did agree that >> it's probably the best we can move to in the near term. My concern is that >> we will have diverged from more "...

...lchain/version. FWIW, back when I worked on it, we were >>>> generally moving towards the idea of canonical triples which contained the >>>> ABI and some lowering code on the user facing interfaces to disambiguate >>>> things like mips64-linux-gnu to mips64-linux-gnuabin32. >>>> > >>>> > >>>> > To reply here a bit: >>>> > >>>> > I worry about target triple being used, but I think I do/did agree >>>> that it's probably the best we can move to in the near term. My concern is >...

...ding on the > OS/distribution/toolchain/version. FWIW, back when I worked on it, we were > generally moving towards the idea of canonical triples which contained the > ABI and some lowering code on the user facing interfaces to disambiguate > things like mips64-linux-gnu to mips64-linux-gnuabin32. > > > > > > > > > To reply here a bit: > > > > > > I worry about target triple being used, but I think I do/did agree > that it's probably the best we can move to in the near term. My concern is > that we will have diverged from more "can...

...ribution/toolchain/version. FWIW, back when I worked on it, we were >>> generally moving towards the idea of canonical triples which contained the >>> ABI and some lowering code on the user facing interfaces to disambiguate >>> things like mips64-linux-gnu to mips64-linux-gnuabin32. >>> > > >>> > > >>> > > To reply here a bit: >>> > > >>> > > I worry about target triple being used, but I think I do/did agree >>> that it's probably the best we can move to in the near term. My concern is &gt...

> On Jan 6, 2020, at 14:29, David Blaikie via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > On Mon, Jan 6, 2020 at 5:58 AM Zakk <zakk0610 at gmail.com <mailto:zakk0610 at gmail.com>> wrote: > > > David Blaikie <dblaikie at gmail.com <mailto:dblaikie at gmail.com>> 於 2020年1月6日 週一 下午2:23寫道： > If this is something that can vary per

Hello LLVM Developers, Within Google, we have a growing range of needs that existing libc implementations don't quite address. This is pushing us to start working on a new libc implementation. Informal conversations with others within the LLVM community has told us that a libc in LLVM is actually a broader need, and we are increasingly consolidating our toolchains around LLVM. Hence, we