search for: dw_form_strx

...thought I'd mention the idea. I agree it's not worth pursuing any further. An API to use that form explicitly (that isn't the normal debug-info generation API) to facilitate testing is fine. Regarding DWARF parsing speed where strings are concerned: DWARF 5 will ruin this because DW_FORM_strx is a ULEB; so, every DIE that has a DW_AT_name or DW_AT_linkage_name will become variable-size (just as bad as DW_FORM_string). In a RelWithDebInfo build of Clang, I got just over 100 million DIEs and 40.2% had DW_AT_name. I didn't try to count DIEs that had DW_AT_linkage_name without DW_A...

...coded.) However, because of the FORM code, we now have whole new worlds of complication regarding where the actual string might be. We might have DW_FORM_strp which puts the actual string in the .debug_string section; eventually we could have DW_FORM_line_str (pointing to .debug_line_str) or even DW_FORM_strx (indirecting through .debug_str_offsets). Conveniently, we have the DWARFFormValue class which knows how to decode data based on what the form code is. Inconveniently, DWARFFormValue assumes it is looking at a .debug_info section, and picks up its relocations from a DWARFUnit. But if we're u...

...oblem is that the same > > strings, again and again, are added to the string pool. Two attributes > > having the same string value would be analyzed (hash calculated) and > > searched inside the string pool. Even if these strings are already in > > string table(DW_FORM_strp, DW_FORM_strx). The process could be optimized > > for string tables. So that if some string from the string table were > > accessed previously then, it would keep a reference into the string pool. > > This would eliminate a lot of string pool searches. > > I'm not sure I fully unders...

...pBucketFor(). The problem is that the same > strings, again and again, are added to the string pool. Two attributes > having the same string value would be analyzed (hash calculated) and > searched inside the string pool. Even if these strings are already in > string table(DW_FORM_strp, DW_FORM_strx). The process could be optimized > for string tables. So that if some string from the string table were > accessed previously then, it would keep a reference into the string pool. > This would eliminate a lot of string pool searches. I'm not sure I fully understand the optimization, b...

On Fri, Nov 18, 2016 at 10:18 AM Eric Christopher <echristo at gmail.com> wrote: > On Fri, Nov 18, 2016 at 8:43 AM Greg Clayton <gclayton at apple.com> wrote: > > > > On Nov 17, 2016, at 5:40 PM, Robinson, Paul <paul.robinson at sony.com> > wrote: > > > > > > > >> -----Original Message----- > >> From: Greg Clayton

Folks, we work on optimization of binary size and improvement of debug info quality. To reduce the size of the binary we use -ffunction-sections so that unused code would be garbage collected. When the linker does garbage collection, a lot of abandoned debug info is left behind. Besides inflated debug info size, we ended up with overlapping address ranges and no way to say valid vs garbage

Hi Eric, please On 31.07.2020 22:02, Eric Christopher wrote: > Hi Alexey, > > On Fri, Jul 31, 2020 at 4:02 AM Alexey Lapshin via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > > On 28.07.2020 19:28, David Blaikie wrote: > > On Tue, Jul 28, 2020 at 8:55 AM Alexey Lapshin > <avl.lapshin at gmail.com