similar to: hexagon port broken?

Hello, I run into a problem that llvm can't write the correct ELFHeaderEFlags for hexagonv4. The following patch can fix it. Index: lib/Target/Hexagon/MCTargetDesc/HexagonMCTargetDesc.cpp =================================================================== --- lib/Target/Hexagon/MCTargetDesc/HexagonMCTargetDesc.cpp (revision 265917) +++

Gang, I'm tasked with direct object generation for Mips and am trying to not hack the code. I how exactly does one set an expression to be PC relative and if the compiler can resolve it, not produce a relocation? In our case, the backend produces an expression for the branch which is the target label. I make a call from the .td for the branch instruction which calls a routine in

Attached is a working patch set for llvm to be able to emit arm64 (currently as triple aarch64-apple-ios) mach-o object files, in case someone is interested. I'm not sure if the llvm maintainers want the patch given the previous message that there's going to be an official patch set from apple to support this, but here is mine. What works (tested on an iPhone 5S): * objc strings,

On Oct 10, 2011, at 10:11 AM, Jack Carter wrote: > Gang, > > I'm tasked with direct object generation for Mips and am trying to not > hack the code. > > I how exactly does one set an expression to be PC relative and if the > compiler can resolve it, not produce a relocation? > Fixups are created for all expressions that may need a relocation. The MC layer evaluates

Hi Jim, The diff below is not intended to be a patch, but a starting point. It is the shortest path (I hope) to getting LLVM to emit ARM mapping symbols to the ELF without changing any shared interfaces. Could you have a look at the FIXME comments and offer some pointers on how to get this code out of MCELFStreamer? Thanks, Greg diff --git a/lib/MC/MCELFStreamer.cpp b/lib/MC/MCELFStreamer.cpp

Attached is an example of how to reproduce the issue. It uses a C file that happens to has a bunch of switch statements which are encoded as jump tables, giving us data-in-code. Usage: To build object files with clang via the -integrated-as versus via GCC: $ export NDK_DIR=<my_ndk_dir> $ export LLVM_DIR=<my_llvm_bin_dir> $ make To test that the generated objects contain the same

Big thanks, i've managed to find what's going on. The thing that dumbfolded me a couple of times was that the error was thrown in one of the MCAssembler methods, but never in applyFixup() itself. On Thu, Jan 19, 2017 at 8:46 PM, Friedman, Eli <efriedma at codeaurora.org> wrote: > On 1/19/2017 10:21 AM, Peter Bel wrote: > >> Hi, >> >> For the function call -

i want to emit binary code for the following implemented vector assembly instructions. P_256B_LOAD_DWORD R_0_R2048b_0, pword ptr [rip + b] P_256B_LOAD_DWORD R_0_R2048b_1, pword ptr [rip + c] P_256B_VADD R_0_R2048b_0, R_0_R2048b_1, R_0_R2048b_0 P_256B_STORE_DWORD pword ptr [rip + a], R_0_R2048b_0 I added the following lines in X86MCInstLower.cpp; unsigned NewOpc; switch (OutMI.getOpcode())

Hi everyone. In ARMAsmBackend.cpp, in routine DarwinARMAsmBackend::ApplyFixup() there is a curious call to getFixupKindNumBytes() - which can return 1,2, 3, or 4 depending upon the FixupKind The code in ApplyFixup() seems to be lifted from the X86. AFAIK, the initial Fixup.Offset() is always divisible by 4, at least for ARM mode - i.e. it is always at the instruction boundary. it looks like

On Nov 15, 2011, at 10:36 AM, Carter, Jack wrote: > Jim, > > Ok, you are where I am in the understanding. This is exactly what I do for relocations applied to code. Now I want to apply fixup information to relocations applied to data. > > The issue I was having was the difficulty of subclassing MCELFStreamer. Or are you saying that I should be messing with the base MCELFStreamer

File: trunk/llvm/lib/Target/Hexagon/CMakeLists.txt set(LLVM_TARGET_DEFINITIONS Hexagon.td) tablegen(LLVM HexagonGenRegisterInfo.inc -gen-register-info) tablegen(LLVM HexagonGenInstrInfo.inc -gen-instr-info) tablegen(LLVM HexagonGenAsmWriter.inc -gen-asm-writer) tablegen(LLVM HexagonGenDAGISel.inc -gen-dag-isel) tablegen(LLVM HexagonGenCallingConv.inc -gen-callingconv) tablegen(LLVM

My apologies. Shouldn't it just be removed since it is now in a subdirectory? On 12/15/2011 11:38 PM, Marc J. Driftmeyer wrote: > File: trunk/llvm/lib/Target/Hexagon/CMakeLists.txt > > set(LLVM_TARGET_DEFINITIONS Hexagon.td) > > tablegen(LLVM HexagonGenRegisterInfo.inc -gen-register-info) > tablegen(LLVM HexagonGenInstrInfo.inc -gen-instr-info) > tablegen(LLVM

> On Hexagon, the slot assignment is determined by the layout of the > instructions in memory. The order of the instructions in the packet does > not matter either in the IR, nor in the .s file, but it does when the > packet is encoded into the actual machine code. In LLVM, the Hexagon > shuffler orders the instructions just prior to encoding. > > Specifically, the

Jim, Both the branch and the branch target are in the same function. This is known delta and should not matter where it is relocated because the delta will remain the same once it is a .o or later. I just want to know how to tell the compiler that this expression is target offset - branch offset. More generally, I want to know the rules for setting up expressions in general. I have no idea if

Jim, Ok, you are where I am in the understanding. This is exactly what I do for relocations applied to code. Now I want to apply fixup information to relocations applied to data. The issue I was having was the difficulty of subclassing MCELFStreamer. Or are you saying that I should be messing with the base MCELFStreamer for a specific fixup. One of the issues I hit initially with llvm is that

On Tue, Nov 15, 2011 at 11:06 AM, Jim Grosbach <grosbach at apple.com> wrote: > > On Nov 15, 2011, at 10:36 AM, Carter, Jack wrote: > >> Jim, >> >> Ok, you are where I am in the understanding. This is exactly what I do for relocations applied to code. Now I want to apply fixup information to relocations applied to data. >> >> The issue I was having was

Hi, I'm trying to implement a 10-bit relocation that does not start at the beginning of a byte-boundary and I'm not entirely sure I understand the use by some targets of MCFixup.Offset and MCFixupKindInfo.TargetOffset. LLVM's documentation states that: MCFixup.Offset -"/// The byte index of start of the relocation inside the encoded instruction."

Hi, For the function call - yes, probably. But what about branching inside one function (standard if-then for example)? For example: echo "int g() { int a = 1; if (a > 3) return 1; return 0; }" | clang -x c - -o /tmp/a.o -c && objdump -d /tmp/a.o Thanks, Petr On Thu, Jan 19, 2017 at 8:06 PM, Friedman, Eli <efriedma at codeaurora.org> wrote: > On 1/19/2017 9:11

Hi, I would like to use a MCFixup to encode the distance in number of bytes from an instruction to the end of the .text section. Is there an existing MCFixup type I can use for this? If not, does anyone have any suggestions for how to add a new MCFixup type that will do this? Thanks, Tom

When I compile this LLVM IR…. @0 = private constant [19 x i8] c"V4main10Brightness\00", section "__TEXT,__swift3_typeref, regular, no_dead_strip" @1 = private constant [9 x i8] c"Vs5UInt8\00", section "__TEXT,__swift3_typeref, regular, no_dead_strip" @2 = private constant [18 x i8] c"currentBrightness\00", section "__TEXT,__swift3_reflstr,