similar to: Multi-architecture (ELF or other) loaders and dynamic linkers available?

On 4/3/2018 9:33 AM, ardi via llvm-dev wrote: > Hi, > > I'm looking for some sort of "universal loader and dynamic linker", > capable of loading in memory an executable (ELF or other, the format > is not a requisite at this time) for any of the "major" architectures > that have LLVM backends (namely: x86, x86_64, ARM, ARM64, PPC, PPC64, > MIPS32,

Hi, Let's suppose we have an ELF executable that doesn't issue any syscall (I mean, syscalls are issued from an external dynamic library, not from the executable, and we can ignore such dynamic library because we have the proper equivalent library with the proper syscalls in MacOS and Windows). So, the question: Is it "currently possible" (by "currently possible" I

> From the provided documentation I understood that in memory data > structures of a PNaCl program are incompatible to the host program because > ABIs are different (e.g. PNaCl pointers are always 32-bit even when running > on x86_64 platform). > So PNaCl program can't access any data structures of the host program > directly. The only communication way is by using syscalls,

Am 19.06.2013 18:01, schrieb JF Bastien: > > From the provided documentation I understood that in memory data > structures of a PNaCl program are incompatible to the host program > because ABIs are different (e.g. PNaCl pointers are always 32-bit > even when running on x86_64 platform). > So PNaCl program can't access any data structures of the host >

On 18 June 2013 15:27, Dmitri Rubinstein <dmitri.rubinstein at googlemail.com>wrote: > Is it possible to use PNaCl infrastructure (i.e. translation and execution > in a sandbox) without a Chrome ? > > I mean a something like a standalone VM like Java or Mono/C#. > Yes. The NaCl tool 'sel_ldr' will run a program inside a sandbox outside of the web browser. We do a

On 4/15/16, Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On Fri, Apr 15, 2016 at 02:31:59PM +0200, ardi via llvm-dev wrote: >> On Fri, Apr 15, 2016 at 1:02 PM, Joerg Sonnenberger via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >> > On Fri, Apr 15, 2016 at 10:45:03AM +0200, ardi via llvm-dev wrote: >> >> What I found is

From the provided documentation I understood that in memory data structures of a PNaCl program are incompatible to the host program because ABIs are different (e.g. PNaCl pointers are always 32-bit even when running on x86_64 platform). So PNaCl program can't access any data structures of the host program directly. The only communication way is by using syscalls, but the document does not

Thanks a lot, but tried it and I get this: CMake Error at projects/libcxx/CMakeLists.txt:361 (message): LIBCXX_ENABLE_STATIC_ABI_LIBRARY is not supported on OS X Why is it not supported? If I manually embed libc++abi.a inside libc++.a it seems to work. Thanks! ardi On Mon, Oct 1, 2018 at 4:20 AM Petr Hosek <phosek at chromium.org> wrote: > > You can use

On Fri, Apr 15, 2016 at 1:02 PM, Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On Fri, Apr 15, 2016 at 10:45:03AM +0200, ardi via llvm-dev wrote: >> What I found is that the build system is really complex, performs many >> checks, and quite often takes wrong decisions (example: a fatal error >> if the OS X version is older than 10.7, instead of

Hi Lang, Yeah, I remember this case. Basically what’s happening is that there are relocations for ELF on x86 that use a value that is present in the object image as part of the calculation for the final value that goes in the same location. If you ever find yourself applying relocations for a second time (for instance, because the loaded object location is remapped for out-of-proc execution)

Looking at tools/clang/lib/Driver/Tools.cpp , there's this fragment of code: if (Args.hasArg(options::OPT_rdynamic) && Version[0] >= 137) CmdArgs.push_back("-export_dynamic"); I built LLVM 3.4.2 from a OS X 10.11 "El Capitan" but specifying a fat build (386+x86_64) and requesting support back up to 10.6. It went fine, and the build passes all tests when run

Hi! I sometimes build LLVM with a static libc++.a in MacOS, so that I use the LLVM libc++ instead of the system-wide one. However, when doing so, I always get link errors when building LLVM, because the build system links with libc++.a, but not with libc++abi.a and so there are quite a few missing symbols that the linker cannot find. My workaround (which always seems to work) is to embed

Hi, I'd like to experiment with the MIPS and PowerPC backends, but, considering that they aren't widely used processors, I'd like to start with the same environment (OS/ABI/linker) used by the people who work with these backends. So, what OS/ABI/linker use the people who use these backends for production work? Thanks!!

Thanks for the reply. I was just asking about in general whatever header files are there in Targets/ for different architectures are not including any function except this processRelocationRef() to be used in RuntimeDyldELF.cpp or RuntimeDyldCOFF.cpp or RuntimeDyldMachO.cpp and i think these files are the ones which are actually doing the relocation and linking work. So what purpose do these

Hi, Can anyone explain in lib/ExecutionEngine/RuntimeDyld/Targets/ the header files included for different architectures like RuntimeDyldCOFFX86_64.h or RuntimeDyldCOFFI386.h etc, what is the connection of these files for relocation and linking as the linking and relocation for diff architecture is done in RuntimeDyldELF.cpp, RuntimeDyldCOFF.cpp and it doesn't use any function from these

Hi, I don't know if there's a wishlist for future LLVM releases but, in case there is one, maybe you'd like to consider my experience (as a multiplatform application developer who discovered clang just because Apple started to include it in Xcode since 10.8 Mountain Lion IIRC, and really liked it, specially for how warnings are issued, which really helps to improve your app code

Thanks for reply, it was really helpful. Can u just be more specific and tell about processRelocationRef() and resolveRelocation() in Targets/RuntimeDyld(objectfile format)(arch).h and also in RuntimeDyldELF.cpp and how the same function is implemented in different ways in both the files ? Thanks, Siddharth On Thu, Apr 20, 2017 at 8:16 PM, mats petersson <mats at planetcatfish.com> wrote:

Thanks. I am just trying to find a relocation and linking design for Hexagon architecture, whether to follow the MIPS style of relocation or other architecture style of relocation. Thats my question . Thats why i was asking about the functions and their differences Please guide. Thanks, Siddharth On Fri, Apr 21, 2017 at 8:37 PM, mats petersson <mats at planetcatfish.com> wrote: > If

Hello, I am working with two different data frames, and I'd like to move data from one to the other. Here is the first frame: > head(five) Week Game.ID VTm VPts HTm HPts HDifferential VDifferential 1 1 NFL_20050908_OAK at NE OAK 20 NE 30 10 -10 2 1 NFL_20050911_ARI at NYG ARI 19 NYG 42 23 -23 3 1 NFL_20050911_CHI

> On Apr 20, 2020, at 1:47 PM, James Y Knight via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > But the most recent NaCL toolchain release is based on LLVM 3.7 from 2015. > > Unless you're planning to upgrade the NaCL toolchain to use a new release based on LLVM devhead (which would seem a rather expensive thing to attempt now, given the plan to desupport it in a