search for: sectiondata

Eli Friedman-2 wrote: > > > Try llvm::Constant::getNullValue(). > > Thanks, that's working nicely (so far). Eli Friedman-2 wrote: > > > Yes; [0 x i32] isn't really a variable-length array, just a > placeholder for an array of unknown size. You have to track the size > yourself. > > This is working, too, however I'm getting a segmentation

...mer : public MCObjectStreamer { > public: > + MCSymbol const *CurSymbol; > + > WinCOFFStreamer(MCContext &Context, > TargetAsmBackend &TAB, > MCCodeEmitter &CE, > raw_ostream &OS); > > + void OnSectionDataCreated(MCSection const *Section, > + MCSectionData *SectionData); > + > + void OnSymbolDataCreated(MCSymbol const *Symbol, > + MCSymbolData *SymbolData); These aren't used, can you just remove them and add them when they actuall...

On Sun, Jul 11, 2010 at 6:10 PM, Chris Lattner <clattner at apple.com> wrote: > This probably needs to be slightly tweaked to work with mainline.  I don't see anything objectionable, but I think Daniel needs to review this one. Updated patch to work with mainline. http://github.com/Bigcheese/llvm-mirror/commit/d19a4c82c18afc4830c09b70f02d162292231c94 - Michael Spencer

...unsigned SectionID, bool IsReadOnly) { return mgr()->allocateDataSection(Size, Alignment, SectionID, IsReadOnly); } virtual void registerEHFrames(llvm::StringRef SectionData) { return mgr()->registerEHFrames(SectionData); } #else virtual uint8_t *allocateDataSection(uintptr_t Size, unsigned Alignment, unsigned SectionID) { return mgr()->allocateData...

...ple, in the good yaml file I >>> see this: >>> >>> - Name: '.debug$H' >>> Characteristics: [ IMAGE_SCN_CNT_INITIALIZED_DATA, >>> IMAGE_SCN_MEM_DISCARDABLE, IMAGE_SCN_MEM_READ ] >>> Alignment: 4 >>> SectionData: >>> C5C93301000001005549419E78044E3896D45CD7009428758BE4A1E2B3E022BA267DEE221F5C42B17BCA182AF84584814A8B5E7E3FB17B397A9E3DEA75CD5627 >>> GlobalHashes: >>> Version: 0 >>> HashAlgorithm: 1 >>> HashValues: >>>...

...>>>> see this: >>>> >>>> - Name: '.debug$H' >>>> Characteristics: [ IMAGE_SCN_CNT_INITIALIZED_DATA, >>>> IMAGE_SCN_MEM_DISCARDABLE, IMAGE_SCN_MEM_READ ] >>>> Alignment: 4 >>>> SectionData: C5C93301000001005549419E78044E >>>> 3896D45CD7009428758BE4A1E2B3E022BA267DEE221F5C42B17BCA182AF8 >>>> 4584814A8B5E7E3FB17B397A9E3DEA75CD5627 >>>> GlobalHashes: >>>> Version: 0 >>>> HashAlgorithm: 1 >>&g...

...is: >>>>> >>>>> - Name: '.debug$H' >>>>> Characteristics: [ IMAGE_SCN_CNT_INITIALIZED_DATA, >>>>> IMAGE_SCN_MEM_DISCARDABLE, IMAGE_SCN_MEM_READ ] >>>>> Alignment: 4 >>>>> SectionData: >>>>> C5C93301000001005549419E78044E3896D45CD7009428758BE4A1E2B3E022BA267DEE221F5C42B17BCA182AF84584814A8B5E7E3FB17B397A9E3DEA75CD5627 >>>>> GlobalHashes: >>>>> Version: 0 >>>>> HashAlgorithm: 1 >>>>...

...unsigned SectionID, > bool IsReadOnly) { > return mgr()->allocateDataSection(Size, Alignment, SectionID, > IsReadOnly); > } > virtual void registerEHFrames(llvm::StringRef SectionData) { > return mgr()->registerEHFrames(SectionData); > } > #else > virtual uint8_t *allocateDataSection(uintptr_t Size, > unsigned Alignment, > unsigned SectionID) { >...

...igned SectionID, >> bool IsReadOnly) { >> return mgr()->allocateDataSection(Size, Alignment, SectionID, >> IsReadOnly); >> } >> virtual void registerEHFrames(llvm::StringRef SectionData) { >> return mgr()->registerEHFrames(SectionData); >> } >> #else >> virtual uint8_t *allocateDataSection(uintptr_t Size, >> unsigned Alignment, >> unsigned Se...

...| 2| 0| 3|int foo() { return 42; } 1| 4|int main() { 1| 5| return 0; 1| 6|} As far I can understand issue somehow related to unused static functions. Also, as I can track down the problem raised because of lib/ProfileData/CoverageMappingReader.cpp (SectionData::get) expects that function's names located inside __llvm_prf_names section but it not true in case of test1.c, instead some function names located inside .rodata section. Is it known issue? any hints, how to avoid or workaround it? -- Be happy, Best regards, Dmitry Volyntsev

...> >>>>>> - Name: '.debug$H' >>>>>> Characteristics: [ IMAGE_SCN_CNT_INITIALIZED_DATA, >>>>>> IMAGE_SCN_MEM_DISCARDABLE, IMAGE_SCN_MEM_READ ] >>>>>> Alignment: 4 >>>>>> SectionData: >>>>>> C5C93301000001005549419E78044E3896D45CD7009428758BE4A1E2B3E022BA267DEE221F5C42B17BCA182AF84584814A8B5E7E3FB17B397A9E3DEA75CD5627 >>>>>> GlobalHashes: >>>>>> Version: 0 >>>>>> HashAlgorithm: 1...

> Sorry, I disagree actually the MachineCodeEmitter or the > 'MachineCodeWritter' does not do any file handling at all. Do look at the > code for the MachineCodeWritter and you will see it only writes to memory > and if it reaches the end of the allotted memory I believe higher ordered > logic reallocates a larget buffer and starts again from scratch. This could > be

...neCodeEmitter class to do this. > ObjectCodeEmitter, is responsible for emission of object 'files' into > a memory buffer. This includes handling of all object headers, > management of sections/segments, symbol and string tables and It writes to sections in ELFWriter::ELFSection.SectionData which are std::vector<unsigned char>. > relocations. The ObjectCodeEmitter should delegate all actual 'data > emission' to the MachineCodeEmitter. No it will have to parallel the MachineCodeEmitter as a generic alternative. > ObjectCodeEmitter is a MachineFunctionPass. It...

On Mon, Mar 16, 2009 at 3:26 AM, Aaron Gray <aaronngray.lists at googlemail.com > wrote: > On Sun, Mar 15, 2009 at 10:52 PM, Aaron Gray < > aaronngray.lists at googlemail.com> wrote: > >> I like the idea of a generic MachineCodeWriter, although I prefer the >>> name 'ObjectFileWriter'... >>> >> >> Thats much more descriptive of

...ng emitted at all. For example, in the good yaml file I >> see this: >> >> - Name: '.debug$H' >> Characteristics: [ IMAGE_SCN_CNT_INITIALIZED_DATA, >> IMAGE_SCN_MEM_DISCARDABLE, IMAGE_SCN_MEM_READ ] >> Alignment: 4 >> SectionData: C5C93301000001005549419E78044E >> 3896D45CD7009428758BE4A1E2B3E022BA267DEE221F5C42B17BCA182AF8 >> 4584814A8B5E7E3FB17B397A9E3DEA75CD5627 >> GlobalHashes: >> Version: 0 >> HashAlgorithm: 1 >> HashValues: >> - 5549...

...to use target/compiler-specific defines outside of libSystem. > struct MCWin32CoffObjectWriter : > MCObjectWriter, > coff::file Any reason for such inheritance? > MCSectionCOFF const & Section = dynamic_cast <MCSectionCOFF const &> (SectionData.getSection ()); LLVM normally compiles w/o RTTI, so this won't work > CoffSection->Header.Characteristics |= > coff::IMAGE_SCN_CNT_CODE | > coff::IMAGE_SCN_ME...

With the correct list this time. On Wed, Sep 9, 2015 at 6:59 PM, Davide Italiano <davide at freebsd.org> wrote: > Hi, > in the last month I spent some time implementing the missing MachO > specific features in llvm-readobj, and converting all the remaining > tests that used macho-dump to the new format. > llvm-readobj should have all the functionality that macho-dump had. If

...> hashes aren't getting emitted at all. For example, in the good yaml file I > see this: > > - Name: '.debug$H' > Characteristics: [ IMAGE_SCN_CNT_INITIALIZED_DATA, > IMAGE_SCN_MEM_DISCARDABLE, IMAGE_SCN_MEM_READ ] > Alignment: 4 > SectionData: > C5C93301000001005549419E78044E3896D45CD7009428758BE4A1E2B3E022BA267DEE221F5C42B17BCA182AF84584814A8B5E7E3FB17B397A9E3DEA75CD5627 > GlobalHashes: > Version: 0 > HashAlgorithm: 1 > HashValues: > - 5549419E78044E38 > - 96D45CD700...

Hi All, I have created a minimally functional Win32 COFF Exporter using the new MC framework. I made some minor changes to other libraries to allow me to plug it in without building it as part of the LLVM project. I wanted to share it but wasn't sure how to go about doing so, so I have attached the code to this message. Any feedback on would be appreciated. -------------- next part

...p in a diff viewer. It looks like the hashes aren't getting emitted at all. For example, in the good yaml file I see this: - Name: '.debug$H' Characteristics: [ IMAGE_SCN_CNT_INITIALIZED_DATA, IMAGE_SCN_MEM_DISCARDABLE, IMAGE_SCN_MEM_READ ] Alignment: 4 SectionData: C5C93301000001005549419E78044E3896D45CD7009428758BE4A1E2B3E022BA267DEE221F5C42B17BCA182AF84584814A8B5E7E3FB17B397A9E3DEA75CD5627 GlobalHashes: Version: 0 HashAlgorithm: 1 HashValues: - 5549419E78044E38 - 96D45CD700942875 - 8BE4A1E2B3E022BA...