search for: initmcobjectfileinfo

...it refers to a nonexistent enum, > > I don't seem to be able to build this with cmake+ninja yet (I'm having > trouble recursing the compiler on macOS) but after manually building it... > It seems this broke at the start of August when the CodeModel argument was > removed from InitMCObjectFileInfo(). After removing that argument and > adding an 'extern "C"' it at least compiles. I haven't had chance to try > running it yet. > > > and for the second one I believe the reason is that it does not enclose > LLVMFuzzerTestOneInput in “extern ‘C’”. > >...

...mInfo> MAI(TheTarget->createMCAsmInfo(*MRI, TripleName)); assert(MAI && "Unable to create target asm info!"); std::string MCPU("generic"); std::string FeaturesStr(""); MCObjectFileInfo MOFI; MCContext Ctx(MAI.get(), MRI.get(), &MOFI); MOFI.InitMCObjectFileInfo(TheTriple, llvm::Reloc::Model::PIC_, llvm::CodeModel::Model::Default, Ctx); std::unique_ptr<MCInstrInfo> MCII(TheTarget->createMCInstrInfo()); std::unique_ptr<MCSubtargetInfo> STI(TheTarget->createMCSubtargetInfo(TripleName, MCPU, FeaturesStr)); OK, that seems, OK. Now...

Hi, As a part of a recent move of libFuzzer from LLVM to compiler-rt I am looking into updating the build code for the libraries which use libFuzzer. I have tried to compile llvm-mc-assemble-fuzzer, and llvm-mc-disassemble-fuzzer, and I couldn’t build either of those. For the first one, the reason is that it refers to a nonexistent enum, and for the second one I believe the reason is that it

...e to fix this. However, O32 should permit "$" in addition to ".L". Even if MipsMCAsmInfo supported multiple prefixes (which is easy enough to add), checking for Triple::mips/mipsel would not yield the correct result on mips64-linux-gnu –mabi=32. * Construct an MCObjectFileInfo * InitMCObjectFileInfo() * FDECFEEncoding is incorrect for N32 (should be sdata4 but gets sdata8 since it checks for Triple::mips64/mips64el) * PersonalityEncoding and TTypeEncoding are correct but only because we don't have a R_MIPS_PC64 relocation yet. If we had such a relocation this would have the same proble...

...e to fix this. However, O32 should permit "$" in addition to ".L". Even if MipsMCAsmInfo supported multiple prefixes (which is easy enough to add), checking for Triple::mips/mipsel would not yield the correct result on mips64-linux-gnu –mabi=32. * Construct an MCObjectFileInfo * InitMCObjectFileInfo() * FDECFEEncoding is incorrect for N32 (should be sdata4 but gets sdata8 since it checks for Triple::mips64/mips64el) * PersonalityEncoding and TTypeEncoding are correct but only because we don't have a R_MIPS_PC64 relocation yet. If we had such a relocation this would have the same proble...

...e to fix this. However, O32 should permit "$" in addition to ".L". Even if MipsMCAsmInfo supported multiple prefixes (which is easy enough to add), checking for Triple::mips/mipsel would not yield the correct result on mips64-linux-gnu –mabi=32. * Construct an MCObjectFileInfo * InitMCObjectFileInfo() * FDECFEEncoding is incorrect for N32 (should be sdata4 but gets sdata8 since it checks for Triple::mips64/mips64el) * PersonalityEncoding and TTypeEncoding are correct but only because we don't have a R_MIPS_PC64 relocation yet. If we had such a relocation this would have the same proble...

...64 but it's possible to fix this. However, O32 should permit "$" in addition to ".L". Even if MipsMCAsmInfo supported multiple prefixes (which is easy enough to add), checking for Triple::mips/mipsel would not yield the correct result on mips64-linux-gnu –mabi=32. · InitMCObjectFileInfo() o FDECFEEncoding is incorrect for N32 (should be sdata4 but gets sdata8 since it checks for Triple::mips64/mips64el) o PersonalityEncoding and TTypeEncoding are correct but only because we don't have a R_MIPS_PC64 relocation yet. If we had such a relocation this would have the same prob...

...e to fix this. However, O32 should permit "$" in addition to ".L". Even if MipsMCAsmInfo supported multiple prefixes (which is easy enough to add), checking for Triple::mips/mipsel would not yield the correct result on mips64-linux-gnu –mabi=32. * Construct an MCObjectFileInfo * InitMCObjectFileInfo() * FDECFEEncoding is incorrect for N32 (should be sdata4 but gets sdata8 since it checks for Triple::mips64/mips64el) * PersonalityEncoding and TTypeEncoding are correct but only because we don't have a R_MIPS_PC64 relocation yet. If we had such a relocation this would have the same proble...

...64 but it's possible to fix this. However, O32 should permit "$" in addition to ".L". Even if MipsMCAsmInfo supported multiple prefixes (which is easy enough to add), checking for Triple::mips/mipsel would not yield the correct result on mips64-linux-gnu –mabi=32. • InitMCObjectFileInfo() o FDECFEEncoding is incorrect for N32 (should be sdata4 but gets sdata8 since it checks for Triple::mips64/mips64el) o PersonalityEncoding and TTypeEncoding are correct but only because we don't have a R_MIPS_PC64 relocation yet. If we had such a relocation this would have the same prob...

...ding = dwarf::DW_EH_PE_pcrel; + TTypeEncoding = dwarf::DW_EH_PE_indirect | dwarf::DW_EH_PE_pcrel | + dwarf::DW_EH_PE_sdata4; + } // .comm doesn't support alignment before Leopard. if (T.isMacOSX() && T.isMacOSXVersionLT(10, 5)) @@ -699,7 +710,7 @@ void MCObjectFileInfo::InitMCObjectFileInfo(StringRef TT, Reloc::Model relocm, if ((Arch == Triple::x86 || Arch == Triple::x86_64 || Arch == Triple::arm || Arch == Triple::thumb || Arch == Triple::ppc || Arch == Triple::ppc64 || - Arch == Triple::UnknownArch) && + Arch == Triple::UnknownArch || Arch ==...

>> Here's the line of thought that I'd like people to start with: >> * Triples don't describe the target. They look like they should, but they >> don't. They're really just arbitrary strings. > >Triples are used as a starting point, but no more. I disagree with this but for now let's assume it's true. The starting point is incorrect because