search for: objectformat

Hi Jack, Can you elaborate a bit on what you're trying to do? Relocations are handled by the ObjectWriter interfaces, not by the streamer. The <ObjectFormat>Streamer classes aren't intended to be subclassed by targets. -Jim On Nov 14, 2011, at 5:50 PM, Carter, Jack wrote: > I need to create a subclass that derives from MCELFStreamer. > > We use MCELFStreamer for direct object generation and need to override a virtual method in the b...

I need to create a subclass that derives from MCELFStreamer. We use MCELFStreamer for direct object generation and need to override a virtual method in the base class MCStreamer::EmitGPRel32Value(). I have been having trouble creating the subclass due to #include issues. I can't seem to get it right at the lib/target/<my target>/MCTargetDesc level. My first thought is always that I am

...uesday, November 15, 2011 8:57 AM To: Carter, Jack Cc: llvmdev at cs.uiuc.edu List; Daniel Dunbar Subject: Re: [LLVMdev] MCELFStreamer subclassing Hi Jack, Can you elaborate a bit on what you're trying to do? Relocations are handled by the ObjectWriter interfaces, not by the streamer. The <ObjectFormat>Streamer classes aren't intended to be subclassed by targets. -Jim On Nov 14, 2011, at 5:50 PM, Carter, Jack wrote: > I need to create a subclass that derives from MCELFStreamer. > > We use MCELFStreamer for direct object generation and need to override a virtual method in the ba...

...gt; To: Carter, Jack > Cc: llvmdev at cs.uiuc.edu List; Daniel Dunbar > Subject: Re: [LLVMdev] MCELFStreamer subclassing > > Hi Jack, > > Can you elaborate a bit on what you're trying to do? Relocations are handled by the ObjectWriter interfaces, not by the streamer. The <ObjectFormat>Streamer classes aren't intended to be subclassed by targets. > > -Jim > > On Nov 14, 2011, at 5:50 PM, Carter, Jack wrote: > >> I need to create a subclass that derives from MCELFStreamer. >> >> We use MCELFStreamer for direct object generation and need...

...> To: Carter, Jack > Cc: llvmdev at cs.uiuc.edu List; Daniel Dunbar > Subject: Re: [LLVMdev] MCELFStreamer subclassing > > Hi Jack, > > Can you elaborate a bit on what you're trying to do? Relocations are handled by the ObjectWriter interfaces, not by the streamer. The <ObjectFormat>Streamer classes aren't intended to be subclassed by targets. > > -Jim > > On Nov 14, 2011, at 5:50 PM, Carter, Jack wrote: > >> I need to create a subclass that derives from MCELFStreamer. >> >> We use MCELFStreamer for direct object generation and need to o...

...;> Cc: llvmdev at cs.uiuc.edu List; Daniel Dunbar >> Subject: Re: [LLVMdev] MCELFStreamer subclassing >> >> Hi Jack, >> >> Can you elaborate a bit on what you're trying to do? Relocations are handled by the ObjectWriter interfaces, not by the streamer. The <ObjectFormat>Streamer classes aren't intended to be subclassed by targets. >> >> -Jim >> >> On Nov 14, 2011, at 5:50 PM, Carter, Jack wrote: >> >>> I need to create a subclass that derives from MCELFStreamer. >>> >>> We use MCELFStreamer for di...

...} @@ -293,6 +298,7 @@ .Case("fsl", Triple::Freescale) .Case("ibm", Triple::IBM) .Case("nvidia", Triple::NVIDIA) + .Case("csr", Triple::CSR) .Default(Triple::UnknownVendor); } @@ -350,26 +356,6 @@ .Default(Triple::UnknownObjectFormat); } -static Triple::SubArchType parseSubArch(StringRef SubArchName) { - return StringSwitch<Triple::SubArchType>(SubArchName) - .EndsWith("v8", Triple::ARMSubArch_v8) - .EndsWith("v8a", Triple::ARMSubArch_v8) - .EndsWith("v7", Triple::ARMSubArch_v7)...

...at cs.uiuc.edu List; Daniel Dunbar >>> Subject: Re: [LLVMdev] MCELFStreamer subclassing >>> >>> Hi Jack, >>> >>> Can you elaborate a bit on what you're trying to do? Relocations are handled by the ObjectWriter interfaces, not by the streamer. The <ObjectFormat>Streamer classes aren't intended to be subclassed by targets. >>> >>> -Jim >>> >>> On Nov 14, 2011, at 5:50 PM, Carter, Jack wrote: >>> >>>> I need to create a subclass that derives from MCELFStreamer. >>>> >>>>...

> > The Triple object will remain unchanged. > > The Tuple will be the API to handle getting/setting parameters > depending on the Triple, compiler flags, attributes, etc. > > This part doesn't seem obvious from the direction the patches are going. > There will be no string representation of all options, as that would > be impossible, or at least, highly

...the ".cfi" suffix on section names that doesn't involve setting a custom section name (which would invoke the "everything goes in the same section" behaviour), and that's to use the confusingly-named "section prefix" feature. If you replace that line with: if (ObjectFormat != Triple::MachO) F->setSectionPrefix(".cfi"); that should make all jump table section names begin with ".text.cfi", which I think should be enough to cause the behaviour needed for cross-DSO CFI here (eugenis can probably confirm). Peter On Tue, May 1, 2018 at 12:59 PM, &l...

...".cfi" suffix on section names that doesn't involve setting a custom section name (which would invoke the "everything goes in the same section" behaviour), and that's to use the confusingly-named "section prefix" feature. If you replace that line with: > if (ObjectFormat != Triple::MachO) F->setSectionPrefix(".cfi"); > that should make all jump table section names begin with ".text.cfi", which I think should be enough to cause the behaviour needed for cross-DSO CFI here (eugenis can probably confirm). > > Peter > > On Tue, Ma...

...fix on section names that > doesn't involve setting a custom section name (which would invoke the > "everything goes in the same section" behaviour), and that's to use the > confusingly-named "section prefix" feature. If you replace that line with: > > if (ObjectFormat != Triple::MachO) F->setSectionPrefix(".cfi"); > > that should make all jump table section names begin with ".text.cfi", > which I think should be enough to cause the behaviour needed for cross-DSO > CFI here (eugenis can probably confirm). > > > > Pet...

...;.cfi" suffix on section names that doesn't involve setting a custom section name (which would invoke the "everything goes in the same section" behaviour), and that's to use the confusingly-named "section prefix" feature. If you replace that line with: > > if (ObjectFormat != Triple::MachO) F->setSectionPrefix(".cfi"); > > that should make all jump table section names begin with ".text.cfi", which I think should be enough to cause the behaviour needed for cross-DSO CFI here (eugenis can probably confirm). > > > > Peter > &...

> On May 30, 2017, at 3:49 PM, Pete Cooper via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> >> On May 30, 2017, at 12:05 PM, Zachary Turner via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Let me try starting over without mentioning Tablegen :) > Aw, but i had a list of issues, such as: > -

That seems to do the trick. I get “symbol ordering file: no such symbol: <blah>” warnings for symbols that didn’t get renamed. Maybe we'll have a separate order file for CFI builds... What about the comment above that line? > On May 1, 2018, at 11:46 AM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > On Tue, May 1, 2018 at 11:29 AM, <dmitry.mikulin at