search for: emitintvalue

Hi all, The AsmPrinter class supports functions like EmitInt8, EmitInt16, and EmitInt32 for writing a 1/2/4 byte directive to the assembly. Each of these calls the MCStreamer::EmitIntValue method with the corresponding size. For some reason, there is no EmitInt64, and I was wondering if there was a fundamental reason why? The EmitIntValue function appears to support 8-byte inputs. I dug into this a bit more and found a commit way back in 2010 (r100296) that removed the "EmitInt...

...ia llvm-dev Sent: Friday, March 09, 2018 7:44 AM To: llvm-dev Subject: [llvm-dev] Why is there no EmitInt64 in AsmPrinter? Hi all, The AsmPrinter class supports functions like EmitInt8, EmitInt16, and EmitInt32 for writing a 1/2/4 byte directive to the assembly. Each of these calls the MCStreamer::EmitIntValue method with the corresponding size. For some reason, there is no EmitInt64, and I was wondering if there was a fundamental reason why? The EmitIntValue function appears to support 8-byte inputs. I dug into this a bit more and found a commit way back in 2010 (r100296) that removed the "EmitInt6...

Hello, I am trying to insert a .byte/.word in the beginning of a specific LLVM IR instruction when it prints out in assembly (the inserted ‘instruction' only appears in assembly, not in LLVM IR), and I am guessing the best way to do that is to insert it in SelectionDAG as it strips down some LLVM IR instructions when it’s lowered. Can I get some guidance on what function I should use to insert

...vidual bytes of larger entities piecemeal. Have you found that not to be the case? The Emit* routines handle endianness for you, so you shouldn't have to do much beyond that. For example, here's the EmitInvValue() implementation that underlies things and does the endianness transform: /// EmitIntValue - Special case of EmitValue that avoids the client having to /// pass in a MCExpr for constant integers. void MCStreamer::EmitIntValue(uint64_t Value, unsigned Size, unsigned AddrSpace) { assert(Size <= 8 && "Invalid size"); assert((isUIntN(8 *...

...vidual bytes of larger entities piecemeal. Have you found that not to be the case? The Emit* routines handle endianness for you, so you shouldn't have to do much beyond that. For example, here's the EmitInvValue() implementation that underlies things and does the endianness transform: /// EmitIntValue - Special case of EmitValue that avoids the client having to /// pass in a MCExpr for constant integers. void MCStreamer::EmitIntValue(uint64_t Value, unsigned Size, unsigned AddrSpace) { assert(Size <= 8 && "Invalid size"); assert((isUIntN(8 *...

...mat is not very good at distinguishing between target-sized bytes (which is the more common use) and 8-bit-bytes. The DWARF standard itself seems not very good in this regard, actually. So we have had to hack our way around this. I.e., at some call-sites of EmitSymbolValue(), EmitLabelDifference(), EmitIntValue() and EmitLabelReference(), an 8-bit-byte-sized argument has had to be converted to target-byte-size (which is extra hacky for odd numbers of eight-bit-bytes). We've been thinking about what a good upstream fix would look like, and believe that perhaps converting all Size arguments in these ca...

...er entities piecemeal. Have you found that not to be the case? > > The Emit* routines handle endianness for you, so you shouldn't have to do much beyond that. For example, here's the EmitInvValue() implementation that underlies things and does the endianness transform: > > /// EmitIntValue - Special case of EmitValue that avoids the client having to > /// pass in a MCExpr for constant integers. > void MCStreamer::EmitIntValue(uint64_t Value, unsigned Size, > unsigned AddrSpace) { > assert(Size <= 8 && "Invalid size"); &gt...

...thing else I missed? > > Another one I noticed. Instead of > >      SmallString<32> *FC = &currFileFragment.getContents(); >      (*FC) += static_cast<char>(attr); >      (*FC) += static_cast<char>(0xFF & v); > > You can do > >     OutStreamer.EmitIntValue(static_cast<char>(attr), 1); >     OutStreamer.EmitIntValue(0xFF & v, 1); > > No? Using the streamer interface looks a lot more in line with what > the rest of the code does. Hmm, I wish we had this discussion way earlier.. How would I emit things in different subsections? I...

Proposal for ELF text and data big endian support for direct object generation Unless I am mistaken, currently big endian support in the MC layer for ELF direct object generation is limited to ELF headers and tables like relocations. Text and data section contents are still generated as individual bytes. It looks as if the effort was started, but never completed. The proposal is to extend the

...at works for Linux, but not for OS X where __register_frame takes a > single FDE at a time. I have an incomplete wip patch if you are > interested. On BSD __register_frame also takes a single argument and therefore needs terminating zero. I also have a simple patch for this: adding Streamer.EmitIntValue(0, 4); at the end of MCDwarfFrameEmitter::Emit in lib/MC/MCDwarf.cpp fixed the issue for me. Somebody needs to check this or similar in. Yuri

...idge when we get there. It might be that the best > thing to do is organize the code so that  we output the subsections in > order. It might be to add some missing feature. For now using the > regular streamer API will make this code a lot easier to read. Of the roughly 111 or so calls to EmitIntValue(), rouighly half are in the Dwarf code, which is cross-architecture. (And they have their own MCSection types to deal with back and forth type issues) Of the 45 remaining, there are 4 interesting uses in MCAsmStreamer.cpp - (I suppose for emitting data constants in a cross platform manner) The oth...

> Hmm, I wish we had this discussion way earlier.. > > How would I emit things in different subsections? I can do a high > level switch to .ARM.attributes, and if I were emitting one blob from > begin to end, using the higher level interface would be preferable, > but it contains additional subsections - which are naturally > represented by MCDataFragments - Is there an MC

...rates symbols like: _ZTIi (TARGET2) While Clang doesn't include the TARGET2 relocation information, and that mess up cross-linking. Looking at the AsmPrinter, when emitting the global constant value (EmitGlobalConstant), it calls EmitGlobalConstantImpl, which end up using EmitValue or EmitIntValue, but neither has relocation information on them. Also, searching the code, I couldn't find any reference to relocation or any of the basic relocation types available in Codesourcery's GCC. Is there anything at all in LLVM regarding relocations? If not, what would be the best place to ad...

> The problem with this is that __register_frame function (in libgcc_s.so), > registering .eh_frame with an exception handler, only takes the pointer to > .eh_frame, and not the size of data, and should be able to detect the end of > data by scanning it and hitting zero DWORD (size). There is no trailing > zero, and it runs into the next section and tries to interpret it as an >

Please look at the fragment of the hex dump of LLVM-created ELF showing the beginning and end of .eh_frame: .eh_frame begin 000297a0 14 00 00 00 00 00 00 00 01 7a 52 00 01 78 10 01 |.........zR..x..| 000297b0 1b 0c 07 08 90 01 00 00 18 00 00 00 1c 00 00 00 |................| <...skipped...> 0002cb00 00 00 00 00 0b 01 00 00 00 41 0e 10 86 02 43 0d |.........A....C.| 0002cb10 06 42

...(Section.empty()) - return; + if (!Section.empty()) { + auto &C = getContext(); + auto *S = C.getELFSection(Section, ELF::SHT_PROGBITS, ELF::SHF_ALLOC); + Streamer.SwitchSection(S); + Streamer.EmitLabel(C.getOrCreateSymbol(StringRef("OBJC_IMAGE_INFO"))); + Streamer.EmitIntValue(Version, 4); + Streamer.EmitIntValue(Flags, 4); + Streamer.AddBlankLine(); + } - auto &C = getContext(); - auto *S = C.getELFSection(Section, ELF::SHT_PROGBITS, ELF::SHF_ALLOC); - Streamer.SwitchSection(S); - Streamer.EmitLabel(C.getOrCreateSymbol(StringRef("OBJC_IMAGE_INFO&qu...