similar to: [LLVMdev] how to emit win32/64 code to elf object file

Displaying 20 results from an estimated 50000 matches similar to: "[LLVMdev] how to emit win32/64 code to elf object file"

2013 Oct 23
0
[LLVMdev] Size limitations in MCJIT / ELF Dynamic Linker/ ELF codegen?
Glad that helped! As I understand it __chkstk is always required on Windows regardless of output type, I had meant to file a bug about this but had apparently forgotten to do so. I think the check needs to be that the target is Windows and ignore the output type, Linux and OSX don't use this. Cheers, Andrew On Wed, Oct 23, 2013 at 11:32 AM, Yaron Keren <yaron.keren at gmail.com>
2013 Oct 23
0
[LLVMdev] Size limitations in MCJIT / ELF Dynamic Linker/ ELF codegen?
This is the right fix if Cygwin wants calls to __chkstk. Otherwise you'll want TargetTriple.isOSMSVCRT(). On Wed, Oct 23, 2013 at 2:50 AM, Yaron Keren <yaron.keren at gmail.com> wrote: > If it's a Windows-only thing the correct tests would be: > > if (NumBytes >= 4096 && STI.isOSWindows()) { > > and > > if (Subtarget->isTargetWindows()) >
2018 Feb 22
0
[cfe-dev] Calling virtual elf functions under windows -> Adding ASM code
Hi Björn, It's correct - I tried casting the virtual function to a regular function. > But I also tried using the virtual function in the normal way. > Yes. If I understand your setup correctly you have a base class, Interface, which is currently compiled into your application, and you are creating a derived class in JIT'd code, and returning an Interface pointer to an instance of
2016 Mar 24
0
[llvm] r263971 - [llvm-objdump] Printing relocations in executable and shared object files. This partially reverts r215844 by removing test objdump-reloc-shared.test which stated GNU objdump doesn't print relocations, it does.
While trying to fix a bug where llvm-objdump isn't printing relocations retained with ld -emit-relocs in shared object or executables, it seems like there isn't a way to split printing dynamic relocations from non-dynamic relocations as with GNU objdump -r and -R. I was thinking of adding a function RelocationRef::isDynamic() and filtering them this way when printing. Since RelocationRef
2013 Oct 23
0
[LLVMdev] Size limitations in MCJIT / ELF Dynamic Linker/ ELF codegen?
Hi Yaron, If you're outputting ELF on Windows this sounds like an issue we ran into where __chkstk calls weren't being output in the assembly due to an explicit check for COFF output. Once stack allocations in a given function exceeded some amount we'd get exactly this kind of crash in the function initialization. If you take a look for isTargetCOFF() in
2013 Oct 23
2
[LLVMdev] Size limitations in MCJIT / ELF Dynamic Linker/ ELF codegen?
If it's a Windows-only thing the correct tests would be: if (NumBytes >= 4096 && STI.isOSWindows()) { and if (Subtarget->isTargetWindows()) where bool isOSWindows() const { return TargetTriple.isOSWindows(); } Yaron 2013/10/23 Andrew MacPherson <andrew.macp at gmail.com> > Glad that helped! As I understand it __chkstk is always required on > Windows
2010 Jun 17
0
[LLVMdev] Relocation issue with jump tables in ELF object files on X86_64
We generating object files, not using the JIT so I don't know if those fixes applies in our case. As far as using PIC goes, the ELFCodeEmitter has asserts to tell you that PIC isn't currently supported. Will have to get the 2.7 update and try it out. Thanks. -----Original Message----- From: Howell, Nathan [mailto:nhowell at ebay.com] Sent: Thursday, June 17, 2010 3:45 PM To: Eli
2013 Oct 23
3
[LLVMdev] Size limitations in MCJIT / ELF Dynamic Linker/ ELF codegen?
YES, this is the problem! The program work ok, even a 5x larger version works well. Clearly the _chkstk calls must be emitted with ELF target on Windows as well - why not? I'd like to make a patch and fix this right. I experimented with both changes and practically only the lib/Target/X86/X86ISelLowering.cpp fixes the problem. The other change lib/Target/X86/X86FrameLowering.cpp was not
2005 Jun 16
3
[LLVMdev] ELF / COFF Summary
We've had various discussions about ELF/COFF support in LLVM. Here's a summary and action plan. 1. Do we need a "reading" interface? * Reid: No * Alexander: Yes * Chris: No * Jeff: We already have this in lib/System (DynamicLibrary.h) 2. Do we support just .so/.exe or all object formats? * Reid: Just .so/.dll .exe and .o * Alexander: Just
2019 Oct 02
2
fixup_aarch64_movw support for COFF AArch64
Martin, Thanks for your suggestion. I look at these tests, try to make them work for COFF. Adam On 2019. 10. 02. 12:23, Martin Storsjö wrote: > On Wed, 2 Oct 2019, Adam Kallai wrote: > >> I'm working Chromium targeting Windows on ARM64 platform. As a part >> of this work I ran into an issue related to llvm in Swiftshader. >> >> Currently fixup_aarch64_movw
2005 Jun 17
0
[LLVMdev] ELF / COFF Summary
On Wed, 15 Jun 2005, Reid Spencer wrote: > So, here's the plan: > > 1. No reading interface. To have a system agnostic interface for reading > a dynamic library, use System/DynamicLibrary. No plans for reading a > native object file for any kind of examination purpose (at least, not > for a long while). Sounds good. > 2. We will support .so/.dll and .o/.obj file output.
2010 Apr 08
2
[LLVMdev] Using LLVM with clang for a homebrew kernel
Hi! In the llvm-doc is the following: Also, since many platforms define their ABIs in terms of C, and since LLVM is lower-level than C, front-ends currently must emit platform-specific IR in order to have the result conform to the platform ABI. Can you give an example for this except system calls (which e.g. on windows use a different calling convention)? If you write your own operating
2013 Feb 03
0
[LLVMdev] RFC: Improving our DWARF (and ELF) emission testing capabilities
On 23.01.2013 00:45, Eli Bendersky wrote: > I do mean semantic extraction which provides a representation that's > meaningful to a user and hence can be effectively compared in a test. > But really, I gave up arguing on this topic a few messages (and heated > IRC discussions) ago. RFC retracted. I actually hit the same predicament for COFF. The few tests that are there usually use
2010 Jun 17
2
[LLVMdev] Relocation issue with jump tables in ELF object files on X86_64
I had this problem a while back and received this response from Jeffrey. FWIW this is fixed in 2.7 by defaulting to CodeModel::Large and using indirect (far) calls. -----Original Message----- From: Jeffrey Yasskin [mailto:jyasskin at google.com] Sent: Monday, December 07, 2009 11:32 AM To: Howell, Nathan Cc: LLVM Developers Mailing List Subject: Re: [LLVMdev] 2.6 JIT using wrong address for
2010 Dec 15
2
[LLVMdev] llvm-mc ELF, macho PEcoff
Hi! I think llvm-mc did amazing work and I'm stunned ;). - So I start reading source-code and making notes. To my question: At which state is the disassembly for PEcoff or ELF? I read the blog (http://blog.llvm.org/2010/04/intro-to-llvm-mc-project.html): """ The MC components have been designed to be object file independent (e.g. work for MachO, ELF, PE-COFF etc) but only have
2010 Nov 26
3
[LLVMdev] request for windows unicode support
On 25.11.2010 23:56, Michael Spencer wrote: > On Nov 25, 2010, at 5:01 PM, Jochen Wilhelmy <j.wilhelmy at arcor.de > <mailto:j.wilhelmy at arcor.de>> wrote: > >> Hi! >> >> Of course nobody wants to implement unicode support for windows >> because windows should support an utf8-locale and windows is obsolete >> anyway ;-) >> >> But
2017 Oct 10
2
Make LLD output COFF relocatable object file (like ELF's -r does). How much work is required to implement this?
TL;DR: I'm trying to evaluate if LLD can be used with GHC (Glasgow Haskell Compiler) on Windows. Haskell binary code is usually deployed in "packages". A package typically provides static library(ies) and optionally – shared library(ies) and/or prelinked ('ld -r') object file. The latter is the best way to satisfy GHC runtime linker, since it requires no separate
2012 Jan 04
0
[LLVMdev] exposing container-specific features in the Object library
Hello, The ObjectFile class (in Object/ObjectFile.h) presents a format-independent interface for object files. In addition, for COFF and MachO, some internal format details are exposed in special headers. For example, Object/COFF.h exposes coff_file_header and coff_symbol. Object/MachOFormat.h exposes headers, "segment load commands" and so on. ELF, however, is not exposed and
2013 Oct 22
2
[LLVMdev] Size limitations in MCJIT / ELF Dynamic Linker/ ELF codegen?
Yes, this is correct code address accessing bad data address. However, there is no other relocation before .text or near it. I'll send you the full debug printout, maybe you'll note something. The problem could be result of something else entirely else than the linker such as some library initialization code that by chance worked with smaller code but fails now. I need to debug and see
2016 Dec 14
2
LLD status update and performance chart
----- Original Message ----- > From: "Sean Silva via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Rui Ueyama" <ruiu at google.com> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Tuesday, December 13, 2016 9:59:37 PM > Subject: Re: [llvm-dev] LLD status update and performance chart > On Tue, Dec 13, 2016 at 12:08 PM, Rui