search for: stringtablebuilder

...e most (-29%) is r250315: ELF2: Merge .{text,rodata,data,bss}.* sections. This is because the commit significantly decreased number of sections in the output. The following commits are also noteworthy. - r257017: ELF: Improve performance of string table construction (-14.0%) - r251332: Optimize StringTableBuilder (-7.8%) Ideally, we should have a perf bot to run a benchmark for every commit, so that we do not accidentally commit changes that hurt performance. Overall, I'm satisfied with the result. It found no commit that increases link time for no justifiable reason. -------------- next part --------...

...E_BLOCK> > <STRTAB_BLOCK> > <STRTAB_BLOB blob="foo\0bar\0baz\0"> > </STRTAB_BLOCK> > > > Why is the string table after the module instead of before? > For implementation simplicity. The idea is that the BitcodeWriter would have a member of type StringTableBuilder which would accumulate strings while writing the bitcode module(s) (and symtab in the future). At the end, the client would call something like BitcodeWriter::writeStrtab() which would write out the string table. > > Each STRTAB_BLOCK would apply to all preceding MODULE_BLOCKs. This means &...

...>> <STRTAB_BLOB blob="foo\0bar\0baz\0"> >> </STRTAB_BLOCK> >> >> >> Why is the string table after the module instead of before? >> > > For implementation simplicity. The idea is that the BitcodeWriter would > have a member of type StringTableBuilder which would accumulate strings > while writing the bitcode module(s) (and symtab in the future). At the end, > the client would call something like BitcodeWriter::writeStrtab() which > would write out the string table. > > > There is already a traversal of the module for value num...

...>> <STRTAB_BLOB blob="foo\0bar\0baz\0"> >> </STRTAB_BLOCK> >> >> >> Why is the string table after the module instead of before? >> > > For implementation simplicity. The idea is that the BitcodeWriter would > have a member of type StringTableBuilder which would accumulate strings > while writing the bitcode module(s) (and symtab in the future). At the end, > the client would call something like BitcodeWriter::writeStrtab() which > would write out the string table. > > >> >> Each STRTAB_BLOCK would apply to all preced...

...ing merge within SHF_MERGE&&SHF_STRINGS sections. We need to pay attention as if a DWARF32 string gets folded into a DWARF64 string, the section referencing the DWARF32 string can still trigger a relocation overflow. If we order DWARF32 components before DWARF64 components, with the llvm::StringTableBuilder usage in LLD, we can make sure DWARF64 strings can get folded into DWARF32 strings, not the other way around. >Is that a correct summary? > >Also I don't quite understand what the issue is with linker script. > >My understanding is that: > >.debug_str 0 : { *(.debug_str) }...

...roposed addition. Walking through the three dynamic entries, 1. DT_SONAME: The value of this entry is a string that will be inserted into the dynamic string table (.dynstr) alongside the symbol names specified in DynamicSymbols. This is possible due to the nature of .dynstr being represented as a StringTableBuilder, and that .dynamic is linked to .dynstr by default. If the .dynamic section had been linked to a section other than .dynstr, the value of this entry would have to be a number (the offset of the string in the linked string table) rather than a string. 2. DT_SYMTAB: This tag may either be a numeric...

...ary. I wouldn't think anyone guarantees or cares about the order of strings within a string section. But I think this would be the very last thing to care about, with regard to DWARF-64 concerns. --paulr > > If we order DWARF32 components before DWARF64 components, with the > llvm::StringTableBuilder usage in LLD, we can make sure DWARF64 strings > can get > folded into DWARF32 strings, not the other way around. > > >Is that a correct summary? > > > >Also I don't quite understand what the issue is with linker script. > > > >My understanding is that: &...

Hi, As part of PR27551 I want to add a string table to the bitcode format to allow global value and comdat names to be shared with the proposed symbol table (and, as side effects, allow comdat names to be shared with value names, make bitcode files more compressible and make bitcode easier to parse). The format of the string table would be a top-level block containing a blob containing

On Fri, Nov 13, 2020 at 11:29 AM David Blaikie <dblaikie at gmail.com> wrote: > > On Fri, Nov 13, 2020 at 11:24 AM Fāng-ruì Sòng <maskray at google.com> wrote: > > > > On Fri, Nov 13, 2020 at 11:17 AM David Blaikie <dblaikie at gmail.com> wrote: > > > > > > On Fri, Nov 13, 2020 at 11:05 AM Fāng-ruì Sòng <maskray at google.com> wrote: >

...Archive Library libLLVMDebugInfoPDB.a make[3]: Leaving directory '/home/NIKHILREDDY/WORK/LLVM_OBJ/lib/DebugInfo/PDB' make[2]: Leaving directory '/home/NIKHILREDDY/WORK/LLVM_OBJ/lib/DebugInfo' llvm[2]: Compiling MachineFunctionAnalysis.cpp for Release+Asserts build llvm[2]: Compiling StringTableBuilder.cpp for Release+Asserts build make[2]: Entering directory '/home/NIKHILREDDY/WORK/LLVM_OBJ/lib/LibDriver' llvm[2]: Building lib Driver Option tables with tblgen llvm[2]: Compiling LibDriver.cpp for Release+Asserts build llvm[2]: Building Release+Asserts Archive Library libLLVMPasses.a make[...