similar to: [LLVMdev] ARM/MC/ELF questions on .ARM.attributes section

> 1. What is the preferred method in MC to jump back to a prior section > already defined? (Or is this not supported?) SetSection in the MCStreamer if you really want to change the current section, but maybe all that you need is to setSection in the Symbol? Similar to what is done in MCELFStreamer::EmitCommonSymbol if the binding is local. > 2. It looks like the "correct" way

I have a question about MCExpr and its subclasses defined in MCExpr.h. I am trying to get Mips' direct object emission working. Line 283 of MCElfStreamer.cpp reads like this: 00283 case MCExpr::Target: llvm_unreachable("Can't handle target exprs yet!"); Does this mean that if I use a subclass of MCTargetExpr to lower MachineOperands to MCOperands, it won't work?

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

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

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

+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 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

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 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 guys, attached are a couple of work in progress patches for ELF support in the MC module. I'm sending this email to gather some general feedback on the code. Applying these patches doesn't get you a fully working llvm-mc that understands ELF; it's just the ground work. I've got a couple more small patches that fixup some places that assume Mach-O object format which I'll

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

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

So, if I understand you correctly the summary is that doing * Build llvm and install it in /foo/bar * Build llvm-gcc and install it in /foo/bar * export PATH=/foo/bar/bin:$PATH * Build llvm again in a unrelated build directory and then running "make check-lit" in the second directory causes /foo/bar/bin/llc and similar tools to be used instead of the recently build tools? If that is

I need to create a subclass that derives from MCELFStreamer. We use MCELFStreamer for direct object generation and need to override a virtual method in the base class MCStreamer::EmitGPRel32Value(). I have been having trouble creating the subclass due to #include issues. I can't seem to get it right at the lib/target/<my target>/MCTargetDesc level. My first thought is always that I am

Hi Jack, Can you elaborate a bit on what you're trying to do? Relocations are handled by the ObjectWriter interfaces, not by the streamer. The <ObjectFormat>Streamer classes aren't intended to be subclassed by targets. -Jim On Nov 14, 2011, at 5:50 PM, Carter, Jack wrote: > I need to create a subclass that derives from MCELFStreamer. > > We use MCELFStreamer for direct

Hi everyone, I am sending this email after some time consuming exploration into how LLVM executes its tests. I first noticed this issue when Rafael noticed that my patch I sent in to llvm-commits broke some tests. I was initially very skeptical, as I had run the make check test from the build directory before sending in the patch, but as it turns out, several issues came together in a perfect

Hi Jim, Daniel, The last time the topic of subclassing MCELFStreamer came up, you both were helpful in identifying ways to handle the use case without requiring subclassing. Can you please take a look at the context below and let me know if you have any suggestions? For reference, this was posted to the list yesterday under the subject "sub-classing MCObjectStreamer?": > Okay,

Getting closer... When emitting symbols, how do I set the symbol's value to the address of the current instruction? Do I need to emit a label in the current section and another that uses the former to point to the latter? If possible, a code sample would be very helpful. And probably questions for Tim, are these "section-relative" mapping symbols, as defined in 4.6.5.1 of the

On 5 October 2012 17:48, Jim Grosbach <grosbach at apple.com> wrote: > The recent MachO data-in-code support should have fixed a lot of the problems. There's probably still some quirks in the specifics ($a vs. $t and making sure the symbols get into the ELF properly), but the core functionality to know how to mark data regions is there and works very well. Hi Jim, I'm trying to

On Oct 7, 2012, at 3:14 AM, Renato Golin <rengolin at systemcall.org> wrote: > On 5 October 2012 17:48, Jim Grosbach <grosbach at apple.com> wrote: >> The recent MachO data-in-code support should have fixed a lot of the problems. There's probably still some quirks in the specifics ($a vs. $t and making sure the symbols get into the ELF properly), but the core