similar to: [LLVMdev] Question about MCExpr and subclasses

That just means the ELF writer doesn't know yet how to deal with the target-specific data. It needs taught how to map them onto relocations and such. Do you really need to subclass MCTargetExpr? That's ordinarily only for operands that aren't representable via the normal MC stuff (for example, the ARM movw/movt relocations). You should be able represent normal symbol operands w/o

HI Akira, Please include the mailing list on replies. Using an MCExpr is the right way to build up things like symbol+offset. ARM has examples for that, as well, which may prove useful. For printing, the target libraries can do that however they want, including using the generic print method for expressions (or not). Often, the generic printing is sufficient, but not always. You can register a

On Tue, Apr 08, 2014 at 04:08:13PM +0400, Robert Khasanov wrote: > Hi Reid, > > Would you approve your patches r203146 and r202774 to be backported to > 3.4.1? They fix stability issues in x86 asm. > Hi Robert, I was able to merge r203146, but it used a c++11 feature: std::string::back() which I replaced with std::string::at(std::string::size() - 1). r202774 was not merged,

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

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

This attempts to address http://llvm.org/bugs/show_bug.cgi?id=18220 It also fixes a test which was requiring the *wrong* output. I'm relatively happy with this part, and it even solves most of the hard part of feature request for .code16 in bug 8684 — which was actually why I started prodding at this. But I could do with some help with the 16-bit signed relocation handling, which I've

+llvmdev -llvmcommits On Fri, Nov 12, 2010 at 8:03 AM, Jim Grosbach <grosbach at apple.com> wrote: > Sorta. getBinaryCodeForInst() is auto-generated by tablegen, so shouldn't be modified directly. The target can register hooks for instruction operands for any special encoding needs, including registering fixups, using the EncoderMethod string. For an example, have a look at the

Hi! I added 2 more tests and also refined an assert statement. Applies cleanly to r148473 now. Are there more comments on the code? Thank you!! Regards Kai On 01.01.2012 22:01, Eli Friedman wrote: > On Sun, Jan 1, 2012 at 10:44 AM, Kai<kai at redstar.de> wrote: >> Happy new year to all! >> >> The attached patch adds TLS support for x86_64-pc-win32 and x86-pc-win32.

Hi everyone, while looking at the ARMAsmPrinter::EmitStartofAsm function, I realized that what looks like singular assembler directives (.eabi_attribute) are in fact shorthand that needs to go in to the .ARM.attributes section in the ELF file. 1. What is the preferred method in MC to jump back to a prior section already defined? (Or is this not supported?) 2. It looks like the

I have a case where I the expression (MCSymbolRefExpr) is the offset from the beginning of the section. The need is to combine that offset to the virtual address of the section it belongs, in this case .text, but it could be any section. I can get a MCSectionELF class object from MCSymbol that I get from MCSymbolRefExpr: int Kind = Value->getKind(); if (Kind == MCExpr::SymbolRef) {

On 17 October 2012 22:23, Greg Fitzgerald <garious at gmail.com> wrote: > I had to move MCELF.h to "include/llvm/MC" and added a > MCELFStreamer.h to the same directory. That okay to do? This is not a trivial question, and I'll let others chip in. Superficially, you'd think so and it might make sense in the long run, but you have to consider why it wasn't there

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 Thu, Jan 19, 2012 at 9:24 AM, Kai <kai at redstar.de> wrote: > Hi! > > I added 2 more tests and also refined an assert statement. Applies cleanly > to r148473 now. Are there more comments on the code? Thank you!! + assert(Inst.getOperand(0).isReg() && + (Inst.getOperand(ImmOp).isImm() || + (Inst.getOperand(ImmOp).isExpr() && +

Hello, I need the expression in string. How can i convert llvm::MCExpr * to string? Please help. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171005/50817330/attachment.html>

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

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

Hi Jack, I'm not 100% up on how MIPS represents jump tables, so take with a grain of salt and all that. Normally how this stuff works is that the streamer will create Fixups (MCDataFragment::addFixup()) for anything that might require a relocation. That may come from the generic streamer stuff (see MCObjectStreamer::EmitValueImpl() for example), or from the target's MCCodeEmitter (for

I ran into a bug in this patch. The mapping symbol produced is aligned and it should not be. Is there a way to configure the MCSymbolRefExpr such that the emitted symbol is unaligned? Alternatively, should the ARM/Thumb code be realigned after a data-in-code section? I notice that GCC leaves it unaligned. Thanks, Greg On Wed, Oct 17, 2012 at 2:32 PM, Renato Golin <rengolin at

Well Jim, that may just be my problem. As background I am working on the outer reaches of llvm for the direct object output for Mips. Part of what I am to do is instruct the folks working closer to the backend what I am getting that is incorrect. My first reaction is to assume that I am being fed things the correct way and that I am not handling it correctly. I feed the compiler a source file

An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191127/dc214059/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: 201911271044539_EW9BEWXX Type: application/octet-stream Size: 13168 bytes Desc: not available URL: