search for: islittleendian

...DT/StringRef.h" #include "llvm/Support/DataTypes.h" diff --git a/lib/DebugInfo/DIContext.cpp b/lib/DebugInfo/DIContext.cpp index ead57f9..691a92c 100644 --- a/lib/DebugInfo/DIContext.cpp +++ b/lib/DebugInfo/DIContext.cpp @@ -19,8 +19,9 @@ DIContext *DIContext::getDWARFContext(bool isLittleEndian, StringRef aRangeSection, StringRef lineSection, StringRef stringSection, - StringRef rangeSection) { + Stri...

On Mon, Nov 5, 2012 at 5:17 PM, Eric Christopher <echristo at gmail.com> wrote: > For llvm-dwarfdump we need to handle relocations inside the debug info > sections in order to successfully dump the dwarf info including strings. > Nick sent out a partial patch that did this not too long ago and I've taken > it and gone in a bit of a different direction, but kept the same basic

...amer::EmitIntValue(uint64_t Value, unsigned Size, unsigned AddrSpace) { assert(Size <= 8 && "Invalid size"); assert((isUIntN(8 * Size, Value) || isIntN(8 * Size, Value)) && "Invalid size"); char buf[8]; const bool isLittleEndian = Context.getAsmInfo().isLittleEndian(); for (unsigned i = 0; i != Size; ++i) { unsigned index = isLittleEndian ? i : (Size - i - 1); buf[i] = uint8_t(Value >> (index * 8)); } EmitBytes(StringRef(buf, Size), AddrSpace); } -Jim On Dec 19, 2011, at 5:17 PM, Carter, Jack wrote:...

...amer::EmitIntValue(uint64_t Value, unsigned Size, unsigned AddrSpace) { assert(Size <= 8 && "Invalid size"); assert((isUIntN(8 * Size, Value) || isIntN(8 * Size, Value)) && "Invalid size"); char buf[8]; const bool isLittleEndian = Context.getAsmInfo().isLittleEndian(); for (unsigned i = 0; i != Size; ++i) { unsigned index = isLittleEndian ? i : (Size - i - 1); buf[i] = uint8_t(Value >> (index * 8)); } EmitBytes(StringRef(buf, Size), AddrSpace); } -Jim On Dec 19, 2011, at 5:17 PM, Carter, Jack wrote:...

...// provides this information). This problem is fixed in DWARFv4 >> + // See this dwarf-discuss discussion for more details: >> + // http://lists.dwarfstd.org/htdig.cgi/dwarf-discuss-dwarfstd.org/2011-December/001173.html >> + DataExtractor debugFrameData(getDebugFrameSection(), isLittleEndian(), >> + getAddressSize()); >> + DebugFrame.reset(new DWARFDebugFrame()); >> + DebugFrame->parse(debugFrameData); >> + return DebugFrame.get(); >> +} >> + >> const DWARFLineTable * >> DWARFContext::getLineTableFo...

...4_t Value, unsigned Size, > unsigned AddrSpace) { > assert(Size <= 8 && "Invalid size"); > assert((isUIntN(8 * Size, Value) || isIntN(8 * Size, Value)) && > "Invalid size"); > char buf[8]; > const bool isLittleEndian = Context.getAsmInfo().isLittleEndian(); > for (unsigned i = 0; i != Size; ++i) { > unsigned index = isLittleEndian ? i : (Size - i - 1); > buf[i] = uint8_t(Value >> (index * 8)); > } > EmitBytes(StringRef(buf, Size), AddrSpace); > } > > -Jim > > On De...

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

Hi, As a first step to port the LLVM chain on an in-house big-endian processor, I'm integrating the native assembler as a new '-assemble -arch=' in llvm-mc. All work quite well, I have a correct output ELF format except that generated code is little-endian. I've understood that the endianess of the LLVM chain is controlled by the DataLayout class, but it appear to me that llvm-mc

...ameData = OrigDwarf.getDWARFObj().getFrameSection().Data; FrameData.substr(EntryOffset, InitialLength + 4) ... InputSec = Dwarf.getDWARFObj().getLocSection(); InputSec.Data.substr(Offset, Length); ... DWARFDataExtractor RangesData(Context.getDWARFObj(), *RangeSection,                               isLittleEndian, getAddressByteSize()); uint64_t ActualRangeListOffset = RangeSectionBase + RangeListOffset; RangeList.extract(RangesData, &ActualRangeListOffset); i.e. It is possible to access random piece of DWARFSection. If object::ObjectFile would contain fragmented sections then we need a solution of h...

...= "\t.skip\t"; CommentString = "!"; ConstantPoolSection = "\t.section \".rodata\",#alloc\n"; } That is wrong for LLVM 3.0 In latest LLVM versions, Sparc have MC subtarget and: SparcELFMCAsmInfo::SparcELFMCAsmInfo(const Target &T, StringRef TT) { IsLittleEndian = false; Triple TheTriple(TT); if (TheTriple.getArch() == Triple::sparcv9) PointerSize = 8; Data16bitsDirective = "\t.half\t"; Data32bitsDirective = "\t.word\t"; Data64bitsDirective = 0; // .xword is only supported by V9. ZeroDirective = "\t.skip\t";...

...his state: - this 0x00000000005fe728 {VarArgsFrameIndex=-842150451 RegSaveFrameIndex=-842150451 VarArgsGPOffset=3452816845 ...} llvm::X86TargetLowering * const + llvm::TargetLowering {TM={...} TD=0x00000000008edac0 IsLittleEndian=true ...} llvm::TargetLowering VarArgsFrameIndex -842150451 int RegSaveFrameIndex -842150451 int VarArgsGPOffset 3452816845 unsigned int...

On Feb 12, 2008, at 5:26 PM, Chuck Rose III wrote: > Hola LLVMers, > > I’m debugging through some strangeness that I’m seeing on X64 on > windows with LLVM2.2. I had to change the code so that it would > engage the x64 target machine on windows builds, but I’ve otherwise > left LLVM 2.2 alone. The basic idea is that I’ve got a function bar > which is compiled by

Hola LLVMers, I'm debugging through some strangeness that I'm seeing on X64 on windows with LLVM2.2. I had to change the code so that it would engage the x64 target machine on windows builds, but I've otherwise left LLVM 2.2 alone. The basic idea is that I've got a function bar which is compiled by VStudio and I'm creating another function foo via LLVM JIT which is going

Hi James, On 05.11.2020 17:59, James Henderson wrote: > (Resending with history trimmed to avoid it getting stuck in moderator > queue). > > Hi Alexey, > > Just an update - I identified the cause of the "Generated debug info > is broken" error message when I tried to build things locally: the > `outStreamer` instance is initialised with the host Triple,

...am &OS, + uint32_t CPUType, + uint32_t CPUSubtype) { + MCMachObjectTargetWriter *MOTW = + new AArch64MachOObjectWriter(CPUType, CPUSubtype); + return createMachObjectWriter(MOTW, OS, /*IsLittleEndian=*/true); +} diff --git a/lib/Target/AArch64/MCTargetDesc/CMakeLists.txt b/lib/Target/AArch64/MCTargetDesc/CMakeLists.txt index 44c66a2..cf045a0 100644 --- a/lib/Target/AArch64/MCTargetDesc/CMakeLists.txt +++ b/lib/Target/AArch64/MCTargetDesc/CMakeLists.txt @@ -6,6 +6,7 @@ add_llvm_library(LLVMAArch...

On Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote: > Can you explain why you chose the approach of using a new pass? > I pictured removing LegalizeDAG's type legalization code would > mostly consist of finding all the places that use TLI.getTypeAction > and just deleting code for handling its Expand and Promote. Are you > anticipating something more

On May 20, 2009, at 1:34 PM, Eli Friedman wrote: > On Wed, May 20, 2009 at 1:19 PM, Eli Friedman > <eli.friedman at gmail.com> wrote: > >> Per subject, this patch adding an additional pass to handle vector >> >> operations; the idea is that this allows removing the code from >> >> LegalizeDAG that handles illegal types, which should be a significant

...ISD::SETLT); - SDValue Zero = DAG.getIntPtrConstant(0), Four = DAG.getIntPtrConstant(4); - SDValue CstOffset = DAG.getNode(ISD::SELECT, dl, Zero.getValueType(), - SignSet, Four, Zero); - uint64_t FF = 0x5f800000ULL; - if (TLI.isLittleEndian()) FF <<= 32; - Constant *FudgeFactor = ConstantInt::get(Type::Int64Ty, FF); - - SDValue CPIdx = DAG.getConstantPool(FudgeFactor, TLI.getPointerTy()); - unsigned Alignment = cast<ConstantPoolSDNode>(CPIdx)->getAlignment(); - CPIdx = DAG.getNode(ISD::ADD, dl, TLI.getPointe...