search for: image_scn_cnt_initialized_data

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

...en 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: C5C93301000001005549419E78044E >>>> 3896D45CD7009428758BE4A1E2B3E022BA267DEE221F5C42B17BCA182AF8 >>>> 4584814A8B5E7E3FB17B397A9E3DE...

...of ST_Other. From: David Majnemer [mailto:david.majnemer at gmail.com] Sent: Friday, August 22, 2014 5:44 PM To: Ted Woodward Cc: LLVM Developers Mailing List Subject: Re: [LLVMdev] possible bug in COFFObjectFile::getSymbolType() COFF sections also contain stuff like IMAGE_SCN_CNT_CODE and IMAGE_SCN_CNT_INITIALIZED_DATA. Are either of those set on the section in question? It may make more sense to try to key off of those section characteristics as well. On Fri, Aug 22, 2014 at 9:55 AM, Ted Woodward <ted.woodward at codeaurora.org> wrote: I’m working on adding data detection to llvm-objdump, so it p...

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

I'm working on adding data detection to llvm-objdump, so it prints out raw data for symbols with type SymbolRef::ST_Data instead of disassembling them. This causes llvm/test/MC/ARM/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

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

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

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

...ection. - */ - memset(&r_sec, 0, sizeof(r_sec)); - strcpy((char *)r_sec.name, ".reloc"); - 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(&a...

...ection. - */ - memset(&r_sec, 0, sizeof(r_sec)); - strcpy((char *)r_sec.name, ".reloc"); - 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(&a...

...yaml a.ghash.bad.obj > 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 >...

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

...d.obj > a.ghash.good.yaml obj2yaml a.ghash.bad.obj > 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 HashVa...

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