search for: mcobjectfileinfo

Hi Rafael, Sure, the expansion of at least .cpload should be done in the Target ELFStreamer but AFAICS it doesn't solve my initial problem. MCCodeGenInfo is not created in tools where CodeGen isn't needed (llvm-mc) and it's still not possible to access the Relocation Model in MCObjectFileInfo from the target streamer (private member). Am I missing something obvious ? There are many ways to work around this issue (some better than others though...): 1) Store Reloc::Model in MCSubtargetInfo. 2) Make MCCodeGenInfo accessible from both worlds (CodeGen and all of the MC layer). 3) Pass R...

...It seems to me that the private label prefixes are more closely associated with the object file format than they are with the assembly syntax so I'd like to propose moving MCAsmInfo::getPrivateGlobalPrefix(), MCAsmInfo::getPrivateLabelPrefix(), and MCAsmInfo::getLinkerPrivateGlobalPrefix() to MCObjectFileInfo and its subclasses. This fixes the Mips case and should have no noticeable impact on other targets. ARM will need some new MCObjectFileInfo classes to handle COFF but other than that, the change seems fairly simple. Does anyone agree/disagree with this change? Have I missed anything? Daniel Sande...

Some Mips macros (e.g. la[1]) and the handling of Mips directives used for Position-Independent Programming (e.g. .cpload[2]) require access to Reloc::Model from within the Assembly Parser but there doesn't seem to be a way to do it in its current form. 1) Reloc::Model is passed to MCObjectFileInfo but it's a private member of that class 2) TargetMachine is not accessible I can also see that clang initializes MCObjectFileInfo with Reloc::Default which isn't entirely right but that's a different matter. I'll come back to that later after we decide what's the right approa...

...tialize the MCAsmInfo earlier than that. IRObjectFile was another problem area. From: Reid Kleckner [mailto:rnk at google.com] Sent: 22 May 2015 16:22 To: Daniel Sanders Cc: LLVM Developers Mailing List (llvmdev at cs.uiuc.edu) Subject: Re: [LLVMdev] Moving Private Label Prefixes from MCAsmInfo to MCObjectFileInfo I think MCAsmInfo was really intended to describe this kind of stuff in the first place. The way I understand it, it's supposed to describe things like "what are the quirks of this target's assembler that I need to know", which includes the private label prefix. That said, it gre...

> From: Renato Golin [renato.golin at linaro.org] > Sent: 26 May 2015 18:43 > To: Daniel Sanders > Cc: Jim Grosbach; LLVM Developers Mailing List (llvmdev at cs.uiuc.edu) > Subject: Re: [LLVMdev] Moving Private Label Prefixes from MCAsmInfo to MCObjectFileInfo > > On 26 May 2015 at 14:58, Daniel Sanders <Daniel.Sanders at imgtec.com> wrote: > > The intention isn't to change the kind of triples/tuples in use by toolchains and > > users. There's a lot of legacy and inertia to overcome if we try that. The intention > >...

On 23 May 2015 at 00:08, Jim Grosbach <grosbach at apple.com> wrote: > This is the key question. The LLVM assumption is that these sorts of things > are inferable from the triple. Your observation here that the GNU world’s > notion of triples and LLVM’s need not be the same is a good one. Having a > split and a translation up in clang seems an interesting avenue to explore. >

On 26 May 2015 at 14:58, Daniel Sanders <Daniel.Sanders at imgtec.com> wrote: > The intention isn't to change the kind of triples/tuples in use by toolchains and users. There's a lot of legacy and inertia to overcome if we try that. The intention is to map the ambiguous/insufficient GNU triples onto an internal representation as early as possible and pass that internal

...uld go into a different text section (text_vle). I can see that TargetMachine has a method getSubtargetImpl which can be overridden for the implementation and it can return different subtargets for different function attributes. What I'm struggling with is connecting it to section selection; in MCObjectFileInfo::initELFMCObjectFileInfo a default text section is created but since here section should be selected based on function, I'm not sure where object file writer implementation should be "connected" to the subtarget info. What would be the appropriate place for this kind of logic? Best...

...| CPU_ARCH_ABI64 @@ -980,6 +996,12 @@ namespace llvm { CPU_SUBTYPE_ARM_V7EM = 16 }; + enum CPUSubTypeARM64 { + CPU_SUBTYPE_ARM64_ALL = 0, + CPU_SUBTYPE_ARM64_V8 = 1 + }; + + enum CPUSubTypeSPARC { CPU_SUBTYPE_SPARC_ALL = 0 }; diff --git a/lib/MC/MCObjectFileInfo.cpp b/lib/MC/MCObjectFileInfo.cpp index 958648c..b5269b6 100644 --- a/lib/MC/MCObjectFileInfo.cpp +++ b/lib/MC/MCObjectFileInfo.cpp @@ -18,14 +18,25 @@ using namespace llvm; void MCObjectFileInfo::InitMachOMCObjectFileInfo(Triple T) { // MachO - IsFunctionEHFrameSymbolPrivate = false; - Sup...

...; "Unable to create target register info!"); std::unique_ptr<MCAsmInfo> 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-&g...

...7 +17,6 @@ #include "llvm/MC/MCAsmBackend.h" #include "llvm/MC/MCAsmInfo.h" #include "llvm/MC/MCContext.h" -#include "llvm/MC/MCCodeEmitter.h" #include "llvm/MC/MCInstPrinter.h" #include "llvm/MC/MCInstrInfo.h" #include "llvm/MC/MCObjectFileInfo.h" @@ -26,7 +25,6 @@ #include "llvm/MC/MCStreamer.h" #include "llvm/MC/MCSubtargetInfo.h" #include "llvm/MC/MCTargetAsmParser.h" -#include "llvm/MC/SubtargetFeature.h" #include "llvm/ADT/OwningPtr.h" #include "llvm/Support/CommandLine...

...9;m currently looking into integrating the patchpoint and stackmap intrinsics into my pet project. In their current implementation (3.4 and trunk) the code to emit the additional section is only executed on Darwin. This is however quickly fixed: Add a ".llvm_stackmaps"-Section for ELF in MCObjectFileInfo and execute StackMaps::serializeToStackMapSection in X86AsmPrinter in the ELF-Branch. serializeToStackMapSection writes the information using MCStreamer, which seems to work properly. I'm using MCJIT with a custom memory manager to intercept the stackmap datasection, but no memory is allocated...

...non-conformant because of the different section names. * Tooling support. Some commonly used consumers have recognized DWARF64. We'll have to teach these tools about new section names. The number of sections to recognize has doubled. This may result in a fair amount of complexity (DWARFContext/MCObjectFileInfo/llvm-dwarfdump -debug* options/ld.lld --gdb-index are things I can immediately think of). On balance I think this is not as good as the section type idea. On Tue, Nov 17, 2020 at 12:17 AM James Henderson <jh7370.2008 at my.bristol.ac.uk> wrote: > > Thinking about it, it would probably...

Hello all! I extended the LDC2 with a pragma to register a funcion in the llvm.global_ctors or llvm.global_dtors list. On Linux, references to these functions are placed in .ctors and .dtors sections and everything runs fine. On Windows, functions from llvm.global_ctors are placed in section .CRT$XCU, which is automatically called by the MS C Runtime. However, functions from

Eli, Yes, SubtargetInfo is more of a container of convenience since it is available to all the assemblers. Working with the current framework it seemed the least disruptive. I'll describe the problem again. The Mips ABI for better or worse, uses the ELF headers e_flags extensively. The most pressing issue is the need to post the relocation model such as PIC, CPIC or non-shared. The object

...use of the different section names. > * Tooling support. Some commonly used consumers have recognized > DWARF64. We'll have to teach these tools about new section names. The > number of sections to recognize has doubled. This may result in a fair > amount of complexity (DWARFContext/MCObjectFileInfo/llvm-dwarfdump > -debug* options/ld.lld --gdb-index are things I can immediately think > of). > > On balance I think this is not as good as the section type idea. > > On Tue, Nov 17, 2020 at 12:17 AM James Henderson > <jh7370.2008 at my.bristol.ac.uk> wrote: > > &gt...

On Fri, Dec 14, 2012 at 1:03 PM, Carter, Jack <jcarter at mips.com> wrote: > Eli, > > This is the kind of feedback I want. I believe I have to add to the base class so it should be generally useful. I can see string being better for the value. I still am enamoured with an enumeration for the tab though: int->string. How would that be a limitation? > I guess that's fine,

This isn't a realistic/viable implementation, just a hacked up "can I make it produce the right output" kind of thing, but while I hammer out a few more details (like fixing MC to allow multiple sections with the same name but different comdat groups) I figured I'd throw it out there to have a bit of a chat about it. I've tested simple cases of a single type and they seem to

On Mon, Nov 16, 2020 at 10:42 PM Igor Kudrin <ikudrin at accesssoftek.com> wrote: > > On 14.11.2020 3:42, Fāng-ruì Sòng wrote: > > For .debug_* in object files: > > > > DWARF32 -> SHT_PROGBITS (unchanged) > > DWARF64 -> SHT_DWARF64 or SHT_GNU_DWARF64 > > > > In LLD, we will need to allow mixed SHT_PROGBITS and SHT_DWARF64. If > > all