search for: emitdataregion

...F properly), but the core functionality to know how to mark data regions is there and works very well. Hi Jim, I'm trying to help Greg crack it down. From your recent commits, I take it you're re-using a data-in-code detection previously used only for ASM output, to object output, via the EmitDataRegion/EmitDataRegionEnd. I haven't looked too deep in the MC, but I'm supposing that will work automatically when the output streamer is printing object code and meets a non-code region, so in theory, changing MCELFStreamer accordingly (overriding those functions in there) would take care of dat...

...lity to know how to mark data regions is there and works very well. > > Hi Jim, > > I'm trying to help Greg crack it down. From your recent commits, I > take it you're re-using a data-in-code detection previously used only > for ASM output, to object output, via the > EmitDataRegion/EmitDataRegionEnd. > It's a bit more than that. Those Emit* methods are new for this support. There was spotty support for the raw $a/$t/$d stuff before, and this abstracted and extended it to support both asm and binary emission as well as added uses for the methods to the various bits in...

On Oct 5, 2012, at 12:15 AM, Tim Northover <t.p.northover at gmail.com> wrote: > Hi Greg, > >> Is this a bug? If so, how can I fix it? > > It's somewhere between a bug and a quality-of-implementation issue. > ARM often uses literal pools in the middle of code when it needs to > materialize a large constant (or variable address more likely for >

...ata regions is there and works very well. >> >> Hi Jim, >> >> I'm trying to help Greg crack it down. From your recent commits, I >> take it you're re-using a data-in-code detection previously used only >> for ASM output, to object output, via the >> EmitDataRegion/EmitDataRegionEnd. >> > > It's a bit more than that. Those Emit* methods are new for this support. There was spotty support for the raw $a/$t/$d stuff before, and this abstracted and extended it to support both asm and binary emission as well as added uses for the methods to the var...

...xt, TAB, OS, Emitter, Assembler), + IsThumb(false), MappingSymbolCounter(0) {} ~MCELFStreamer() {} @@ -58,6 +60,7 @@ public: virtual void EmitLabel(MCSymbol *Symbol); virtual void EmitAssemblerFlag(MCAssemblerFlag Flag); virtual void EmitThumbFunc(MCSymbol *Func); + virtual void EmitDataRegion(MCDataRegionType Kind); virtual void EmitAssignment(MCSymbol *Symbol, const MCExpr *Value); virtual void EmitWeakReference(MCSymbol *Alias, const MCSymbol *Symbol); virtual void EmitSymbolAttribute(MCSymbol *Symbol, MCSymbolAttr Attribute); @@ -108,6 +111,7 @@ public: private: virtual...

...very well. >>> >>> Hi Jim, >>> >>> I'm trying to help Greg crack it down. From your recent commits, I >>> take it you're re-using a data-in-code detection previously used only >>> for ASM output, to object output, via the >>> EmitDataRegion/EmitDataRegionEnd. >>> >> >> It's a bit more than that. Those Emit* methods are new for this support. There was spotty support for the raw $a/$t/$d stuff before, and this abstracted and extended it to support both asm and binary emission as well as added uses for the meth...

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

...econd; + MCStreamer &Streamer = getParser().getStreamer(); + Streamer.SwitchSection(Section); + Streamer.EmitLabel(CP.getLabel()); + for (size_t I = 0; I < CP.getNumEntries(); ++I) + Streamer.EmitValue(CP.getEntry(I), 4); + } +} This is missing data-in-code indicators (see EmitDataRegion()). + at RUN: clang -target arm -integrated-as -c %s -o %t + at RUN: llvm-objdump -d %t | FileCheck %s + at RUN: llvm-objdump -r %t | FileCheck --check-prefix=RELOC %s MC tests should not call clang. There is no guarantee that clang will be present on the system or being built in the current LLV...

Moving discussion to llvm-commits now that I have a more developed implementation: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20131111/195401. html > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On > Behalf Of David Peixotto > Sent: Tuesday, November 12, 2013 11:09 AM > To: 'Amara Emerson' >

...etParser().getStreamer(); > + Streamer.SwitchSection(Section); > + Streamer.EmitLabel(CP.getLabel()); > + for (size_t I = 0; I < CP.getNumEntries(); ++I) > + Streamer.EmitValue(CP.getEntry(I), 4); > + } > +} > > This is missing data-in-code indicators (see EmitDataRegion()). I was not aware of that API, thanks for pointing it out. I added the calls in the latest patch. See the ConstantPool::emitEntries() method. > + at RUN: clang -target arm -integrated-as -c %s -o %t > + at RUN: llvm-objdump -d %t | FileCheck %s > + at RUN: llvm-objdump -r %t | FileChec...

...t; + Streamer.SwitchSection(Section); >> + Streamer.EmitLabel(CP.getLabel()); >> + for (size_t I = 0; I < CP.getNumEntries(); ++I) >> + Streamer.EmitValue(CP.getEntry(I), 4); >> + } >> +} >> >> This is missing data-in-code indicators (see EmitDataRegion()). > > I was not aware of that API, thanks for pointing it out. I added the calls > in the latest patch. See the ConstantPool::emitEntries() method. > >> + at RUN: clang -target arm -integrated-as -c %s -o %t >> + at RUN: llvm-objdump -d %t | FileCheck %s >> + at RU...