similar to: [LLVMdev] MC ELF support

Hi Matt, Awesome! This is excellent progress, and it is great to see someone working on this. High level comments: (1) The order of patches is odd, to me. It would be great to start by adding the AsmParser support, then the MCStreamer support, so that we can have test cases in the 'llvm-mc cat' mode, where it just parses and prints out again. On 0001: - What is hasRelocationAddend? It

On Sun, Jul 11, 2010 at 6:10 PM, Chris Lattner <clattner at apple.com> wrote: > This probably needs to be slightly tweaked to work with mainline.  I don't see anything objectionable, but I think Daniel needs to review this one. Updated patch to work with mainline. http://github.com/Bigcheese/llvm-mirror/commit/d19a4c82c18afc4830c09b70f02d162292231c94 - Michael Spencer

Hi Akira, This is looking good. Some specific comments on the details below. Thanks! Jim > diff --git a/include/llvm/MC/MCELFObjectWriter.h b/include/llvm/MC/MCELFObjectWriter.h > index 6e9f5d8..220ecd0 100644 > --- a/include/llvm/MC/MCELFObjectWriter.h > +++ b/include/llvm/MC/MCELFObjectWriter.h > @@ -13,6 +13,7 @@ > #include "llvm/MC/MCObjectWriter.h" >

I have been working on getting ELF object file writing working for the MBlaze backend. Currently, each supported backend calls ELFObjectWriter::createELFObjectWriter from within the backend's TargetAsmBackend::createObjectWriter method. The createELFObjectWriter method then creates a new backend specific ELFObjectWriter class (either X86ELFObjectWriter or ARMELFObjectWriter) by decoding a

Hi Jim, Thanks for reviewing the patch. I couldn't get rid of STLExtras.h, but other than that, I followed all the suggestions in your email. Please let me know if you notice anything else that needs fixing. On Thu, Mar 22, 2012 at 4:42 PM, Jim Grosbach <grosbach at apple.com> wrote: > Hi Akira, > > This is looking good. Some specific comments on the details below. > >

Hi Akira, Just two very minor things that I missed the first time around. 1. The 'fixup" member of ELFRelocation entry should be "Fixup" instead. 2. Since we're always passing in a non-NULL fixup, that should probably be a reference, not a pointer. Good for commit with those tweaks. Thanks! -Jim On Mar 23, 2012, at 1:07 PM, Akira Hatanaka wrote: > Hi Jim, >

Here is the patch. On Thu, Mar 22, 2012 at 11:11 AM, Akira Hatanaka <ahatanak at gmail.com> wrote: > Hi Jim, > > Yes, the relocation entries have to be reordered so that the > got16/lo16 or hi16/lo16 pairs appear consecutively in the relocation > table. As a result, relocations can appear in a different order than > the instructions that they're for. > > For

On 3 May 2017 at 08:01, Rafael Avila de Espindola via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Can you provide a .s file that shows the difference? I managed to reproduce it by compiling 'char *var = "whatever";' in debug mode (so clang -target arm-none-eabi tmp.c -g"). Direct compile leaves no assembler-local strings, but for some reason going via -S does.

Hi Jim, Yes, the relocation entries have to be reordered so that the got16/lo16 or hi16/lo16 pairs appear consecutively in the relocation table. As a result, relocations can appear in a different order than the instructions that they're for. For example, in this code, the post-RA scheduler inserts an instruction with relocation %got(body_ok) between %got(scope_top) and %lo(scope_top). $ cat

Hi, I was looking at the ARM ABI docs(http://infocenter.arm.com/help/topic/com.arm.doc.ihi0044e/IHI0044E_aaelf.pdf) and they mention. "A binary file may use REL or RELA relocations or a mixture of the two (but multiple relocations for the same address must use only one type)." Does LLVM emit rel/rela relocations with ARM ? Any tests ? Thanks Shankar Easwaran -- Qualcomm

Hi all, I have reached the relocation phase of my backend implementation and I'm having some trouble. The LLVM code I'm trying to compile is this: %struct.Date = type { i32, i32, i32 } @date = global %struct.Date { i32 2012, i32 10, i32 120000 }, align 4 ; Function Attrs: nounwind define i32 @foo() #0 { %1 = load i32, i32* getelementptr inbounds (%struct.Date, %struct.Date* @date, i32

On May 5, 2010, at 5:22 PM, Nathan Jeffords wrote: > > The logic to handle this has to go somewhere, putting it in the MCStreamer *implementation* that needs it is the most logical place. We also aim to implement an assembler, it doesn't make sense to duplicate this logic in the compiler and the assembler parser. > > > Assembly language has often been *the* intermediate

Hi Shankar, > Does LLVM emit rel/rela relocations with ARM ? I believe we emit .rel for (32-bit) ARM. Hard-coded in ARMELFObjectWriter.cpp (“HasRelocationAddend”). It seems to be what most toolchains have settled on. AArch64 is .rela always in LLVM, in case it matters. > Any tests ? Well there are tests of what we do, but obviously not of the full scope of functionality permitted by the

On Wed, May 5, 2010 at 5:53 PM, Chris Lattner <clattner at apple.com> wrote: > > On May 5, 2010, at 5:22 PM, Nathan Jeffords wrote: >> >> The logic to handle this has to go somewhere, putting it in the MCStreamer >> *implementation* that needs it is the most logical place.  We also aim to >> implement an assembler, it doesn't make sense to duplicate this

Hi Chris, Thanks for taking time to communicate on this. In your open points, you speak about upgrading the JIT code path. If I want to take a look (or at least try...) on it, what would be the "roadmap" ? I assume, a MCJITStreamer is needed. And probably a JITObjectWriter (inherits from MCObjectWriter) and an associated TargetAsmBackend specific to the JIT (JITX86AsmBackend) ? What

Hi Michael, Overall patch looks good. I do have a few comments below. My main comment is please try to make the style match that used in the MCMachOStreamer more closely. I intend to refactor more functionality into the base MCObjectStreamer class, and having them use consistent idioms makes this easier; specific instances are included in the comments: -- > diff --git

I have been looking over AsmPrinter::EmitLinkage (around line 195 of lib\CodeGen\AsmPrinter\AsmPrinter.cpp) and it seems that its implementation will vary quite a bit depending on what object file format is in use (MachO, ELF, or COFF). Would it make sense to delegate the implementation to a specialized object from current the object file format? I am tempted to make it the MCAsmInfo

Here is a full patch including Nathan's COFF support, tests that pass on Windows, and some changes to lit. Obviously the COFF support and changes to lit should be separate patches in the end. http://codereview.appspot.com/1624043/show - Michael Spencer -------------- next part -------------- A non-text attachment was scrubbed... Name: COFF-support.patch Type: application/octet-stream Size:

Hi, there are a couple of possible issues around array_pod_sort from STLExtras.h . Firstly, qsort() needs a comparator that returns zero on equal inputs. ConstantIntSortPredicate in SimplifyCFG.cpp (where the sort is being used to bring duplicate values together) fails this requirement. All the others look ok. Secondly, on Windows qsort() needs its callback to use __cdecl calling convention,

On Apr 11, 2010, at 10:35 AM, Olivier Meurant wrote: > Hi Chris, > > Thanks for taking time to communicate on this. Sorry I missed responding to this email sooner. > In your open points, you speak about upgrading the JIT code path. If I want to take a look (or at least try...) on it, what would be the "roadmap" ? > > I assume, a MCJITStreamer is needed. > And