search for: image_scn_mem_read

...ov32t-range.s to fail, because the symbol "truncation" comes back as SymbolRef::ST_Data, and the code gets dumped as bytes instead of disassembled. I traced the problem back to COFFObjectFile::getSymbolType() in llvm/lib/Object/COFFObjectFile.cpp : if (Characteristics & COFF::IMAGE_SCN_MEM_READ && ~Characteristics & COFF::IMAGE_SCN_MEM_WRITE) // Read only. Result = SymbolRef::ST_Data; I think it should also check for ~Characteristics & COFF::IMAGE_SCN_MEM_EXECUTE. The symbol, in this case, is READ, EXECUTE, !WRITE. if (Characteristics & COFF...

.../Windows/mov32t-range.s to fail, because the symbol “truncation” comes back as SymbolRef::ST_Data, and the code gets dumped as bytes instead of disassembled. I traced the problem back to COFFObjectFile::getSymbolType() in llvm/lib/Object/COFFObjectFile.cpp : if (Characteristics & COFF::IMAGE_SCN_MEM_READ && ~Characteristics & COFF::IMAGE_SCN_MEM_WRITE) // Read only. Result = SymbolRef::ST_Data; I think it should also check for ~Characteristics & COFF::IMAGE_SCN_MEM_EXECUTE. The symbol, in this case, is READ, EXECUTE, !WRITE. if (Characteristics & COFF...

...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 >>>...

...t; 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: C5C93301000001005549419E78044E >>>> 3896D45CD7009428758BE4A1E2B3E022BA267DEE221F5C42B17BCA182AF8 >>>> 4584814A8B5E7E3FB17B397A9E3DEA75CD5627 >>>> GlobalHashes: >>>>...

...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: >>>>>...

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

...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: >>&...

...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: C5C93301000001005549419E78044E >> 3896D45CD7009428758BE4A1E2B3E022BA267DEE221F5C42B17BCA182AF8 >> 4584814A8B5E7E3FB17B397A9E3DEA75CD5627 >> GlobalHashes: >> Version: 0 >> HashAlgori...

...loc"); - r_sec.virtual_sz = sizeof(c_rel); - r_sec.virtual_address = ftell(f) + sizeof(r_sec); - r_sec.raw_data_sz = r_sec.virtual_sz; - r_sec.raw_data = r_sec.virtual_address; - r_sec.characteristics = IMAGE_SCN_CNT_INITIALIZED_DATA | - IMAGE_SCN_ALIGN_1BYTES | IMAGE_SCN_MEM_DISCARDABLE | - IMAGE_SCN_MEM_READ; - fwrite(&r_sec, sizeof(r_sec), 1, f); - - memset(&c_rel, 0, sizeof(c_rel)); - c_rel.virtual_address = ftell(f) + sizeof(c_rel); - c_rel.symtab_index = 10; - fwrite(&c_rel, sizeof(c_rel), 1, f); - fwrite(&dummy, sizeof(dummy), 1, f); - - /* * Add some padding to align the ELF as...

The PE headers of the generated efi file were quite buggy. And since OVMF perform a few consistency checks, syslinux was unable to run on it. I don't pretend to have a thorough understanding of the PE+ headers, some bugs may remain. :) Celelibi (4): efi: Fix PE header field rva_and_sizes_nr efi: Location, size and alignment of .text section efi: Useless relocations in PE file efi: PE

...loc"); - r_sec.virtual_sz = sizeof(c_rel); - r_sec.virtual_address = ftell(f) + sizeof(r_sec); - r_sec.raw_data_sz = r_sec.virtual_sz; - r_sec.raw_data = r_sec.virtual_address; - r_sec.characteristics = IMAGE_SCN_CNT_INITIALIZED_DATA | - IMAGE_SCN_ALIGN_1BYTES | IMAGE_SCN_MEM_DISCARDABLE | - IMAGE_SCN_MEM_READ; - fwrite(&r_sec, sizeof(r_sec), 1, f); - - memset(&c_rel, 0, sizeof(c_rel)); - c_rel.virtual_address = ftell(f) + sizeof(c_rel); - c_rel.symtab_index = 10; - fwrite(&c_rel, sizeof(c_rel), 1, f); - fwrite(&dummy, sizeof(dummy), 1, f); - - /* * Add some padding to align the ELF as...

...(SectionData.getSection ()); LLVM normally compiles w/o RTTI, so this won't work > CoffSection->Header.Characteristics |= > coff::IMAGE_SCN_CNT_CODE | > coff::IMAGE_SCN_MEM_READ | > coff::IMAGE_SCN_MEM_EXECUTE | > false; Was "| false" intentional? Why? > default: > report_fatal_error_dbg (&quot...

...l_sz = total_sz; - t_sec.raw_data_sz = total_sz; + t_sec.virtual_sz = data_size; + t_sec.virtual_address = hdr_sz; + t_sec.raw_data_sz = t_sec.virtual_sz; + t_sec.raw_data = t_sec.virtual_address; t_sec.characteristics = IMAGE_SCN_CNT_CODE | IMAGE_SCN_ALIGN_16BYTES | IMAGE_SCN_MEM_EXECUTE | IMAGE_SCN_MEM_READ; @@ -163,6 +159,16 @@ static void write_header(FILE *f, __uint32_t entry, size_t data_size, fwrite(&c_rel, sizeof(c_rel), 1, f); fwrite(&dummy, sizeof(dummy), 1, f); + /* + * Add some padding to align the ELF as needed + */ + if (ftell(f) > t_sec.virtual_address) { + // A fseek...

...hese 2 yaml files up 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: >...

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

...a.ghash.bad.yaml Then open these 2 yaml files up 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 - 96D4...

...> + SectionName.append(Symbol->getName().begin(), Symbol->getName().end()); > + > + MCSymbolData *SymbolData = getSymbolData(Symbol); > + > + unsigned Characteristics = > + COFF::IMAGE_SCN_LNK_COMDAT | > + COFF::IMAGE_SCN_CNT_UNINITIALIZED_DATA | > + COFF::IMAGE_SCN_MEM_READ | > + COFF::IMAGE_SCN_MEM_WRITE; > + > + int Selection = COFF::IMAGE_COMDAT_SELECT_LARGEST; > + > + MCSection const *Section = MCStreamer::getContext().getCOFFSection( > + SectionName, Characteristics, Selection, SectionKind::getBSS() > + ); Please spell the type as &...

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

I'm so close I can almost smell it :) I know how bad the code looks, I don't intend to submit this, but if you want to try it out its at: https://gist.github.com/santagada/544136b1ee143bf31653b1158ac6829e I'm seeing: lld-link.exe: error: duplicate symbol: "<redacted_unmangled>" (<redacted>) in <internal> and in <redacted_filename>.obj, looking at the