search for: getkindforglobal

...e much of the IsGlobalInSmallSection handling from the MIPS target, but perform the same basic classification tasks: 1. Pass GlobalObject to target-declared IsGlobalInSmallSection. If it's a declaration, skip to step 4. 2. Pass GlobalObject to target-independent TargetLoweringObjectFile::getKindForGlobal. 3. Ensure the returned SectionKind is Data, BSS or Common. 4. Pass GlobalObject to target-specific IsGlobalInSmallSectionImpl, which scrutinizes the object's type for the specific architecture. I believe this redundant implementation between targets can be reduced by giving SectionKind an...

...llSection handling from the MIPS target, but perform the same basic classification tasks: > > 1. Pass GlobalObject to target-declared IsGlobalInSmallSection. > If it's a declaration, skip to step 4. > 2. Pass GlobalObject to target-independent > TargetLoweringObjectFile::getKindForGlobal. > 3. Ensure the returned SectionKind is Data, BSS or Common. > 4. Pass GlobalObject to target-specific IsGlobalInSmallSectionImpl, > which scrutinizes the object's type for the specific architecture. > > I believe this redundant implementation between targets can be reduced...

...target, but perform > > the same basic classification tasks: > > > > 1. Pass GlobalObject to target-declared IsGlobalInSmallSection. > > If it's a declaration, skip to step 4. > > 2. Pass GlobalObject to target-independent > > TargetLoweringObjectFile::getKindForGlobal. > > 3. Ensure the returned SectionKind is Data, BSS or Common. > > 4. Pass GlobalObject to target-specific IsGlobalInSmallSectionImpl, > > which scrutinizes the object's type for the specific > > architecture. > > > > I believe this redundant implemen...

Here is a module: @vals = internal unnamed_addr global [20000000 x i32] undef, align 4 When I compile it into an .o file: $ clang -c test.ll $ objdump -t test.o test.o: file format elf64-x86-64 SYMBOL TABLE: 0000000000000000 l df *ABS* 0000000000000000 test.ll 0000000000000000 l O .data 0000000004c4b400 vals LLVM puts the global in the .data section, and results in a 77MB .o file

...in the .data section, and results in a 77MB .o file >> of mostly zeroes. Why does this variable not go in the .bss section? >> >> > I think it's just an oversight; it doesn't matter for clang because it > never emits globals like that. See TargetLoweringObjectFile::getKindForGlobal > for the relevant logic. I see, thanks. Would a patch be welcome which changed this behavior? Or I suppose I could emit zeroinitializer instead of undef. But it seems like undef is the more correct value. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http...

Alexander, On Darwin the "__cstring" section (really section with type S_CSTRING_LITERAL) is defined to contain zero terminate strings of bytes that the linker can merge and re-order. If you want pad bytes before and after the string, you need to put the strings in a different section (e.g. __TEXT, __const). But, CF/NSString literals will be problematic. The compiler emits a static

(forgot to CC llvmdev) On Thu, Mar 21, 2013 at 5:54 PM, Alexander Potapenko <glider at google.com> wrote: > Hey Anna, Nick, Ted, > > We've the following problem with string literals under ASan on Mac. > Some global string constants end up being put into the .cstring > section, for which the following rules apply: > - the strings can't contain zeroes in their

...ZN4llvm21UnwindTablesMandatoryE$non_lazy_ptr in libLLVMAsmPrinter.a(DwarfException.cpp.o) "llvm::TargetData::init(llvm::StringRef)", referenced from: llvm::TargetData::TargetData(llvm::StringRef)in libLLVMEBCCodeGen.a(EBCTargetMachine.cpp.o) "llvm::TargetLoweringObjectFile::getKindForGlobal(llvm::GlobalValue const*, llvm::TargetMachine const&)", referenced from: llvm::AsmPrinter::EmitGlobalVariable(llvm::GlobalVariable const*)in libLLVMAsmPrinter.a(AsmPrinter.cpp.o) llvm::TargetLoweringObjectFile::SectionForGlobal(llvm::GlobalValue const*, llvm::Mangler*, llvm::Ta...