search for: gnu_pubnam

...hopefully someone will commit it. cheers, dlg Index: include/llvm/Support/Dwarf.def =================================================================== --- include/llvm/Support/Dwarf.def (revision 301500) +++ include/llvm/Support/Dwarf.def (working copy) @@ -343,6 +343,8 @@ HANDLE_DW_AT(0x2134, GNU_pubnames, 0, GNU) HANDLE_DW_AT(0x2135, GNU_pubtypes, 0, GNU) HANDLE_DW_AT(0x2136, GNU_discriminator, 0, GNU) +// Sun Extension +HANDLE_DW_AT(0x2224, SUN_amd64_parmdump, 0, GNU) // Borland extensions. HANDLE_DW_AT(0x3b11, BORLAND_property_read, 0, BORLAND) HANDLE_DW_AT(0x3b12, BORLAND_property_write,...

...lg > > Index: include/llvm/Support/Dwarf.def > =================================================================== > --- include/llvm/Support/Dwarf.def (revision 301500) > +++ include/llvm/Support/Dwarf.def (working copy) > @@ -343,6 +343,8 @@ > HANDLE_DW_AT(0x2134, GNU_pubnames, 0, GNU) > HANDLE_DW_AT(0x2135, GNU_pubtypes, 0, GNU) > HANDLE_DW_AT(0x2136, GNU_discriminator, 0, GNU) > +// Sun Extension > +HANDLE_DW_AT(0x2224, SUN_amd64_parmdump, 0, GNU) > // Borland extensions. > HANDLE_DW_AT(0x3b11, BORLAND_property_read, 0, BORLAND) > HANDLE_DW_...

...rt/Dwarf.def >>> =================================================================== >>> --- include/llvm/Support/Dwarf.def (revision 301500) >>> +++ include/llvm/Support/Dwarf.def (working copy) >>> @@ -343,6 +343,8 @@ >>> HANDLE_DW_AT(0x2134, GNU_pubnames, 0, GNU) >>> HANDLE_DW_AT(0x2135, GNU_pubtypes, 0, GNU) >>> HANDLE_DW_AT(0x2136, GNU_discriminator, 0, GNU) >>> +// Sun Extension >>> +HANDLE_DW_AT(0x2224, SUN_amd64_parmdump, 0, GNU) >>> // Borland extensions. >>> HANDLE_DW_AT(0x3b11, BORLAND...

...come up with a theory about how to address it). Compared to getting in > the way of the automated path to a working executable. > > > --gdb-index, > > upcoming --debug-names. > > Importantly, these can be produced without parsing a lot of DWARF if > the input contains gnu_pubnames, or debug_names (yeah, currently > gdb_index still is quite costly (but I think more like 10s of percent > in link time, not multiple 100s of percent) in memory and link time > even when it's only parsing gnu_pubnames. > > > From the design point of view, it would be > &g...

>On 2020-06-22, Alexey Lapshin via llvm-dev wrote: >>>> >> >Alexey> Probably we could try to make DWARF easy to parsing, trimming, rewriting so that full DWARF >>>> >> >Alexey> parsing solution would not take too much time? >>>> >> >Alexey> >>>> >> >Alexey> f.e. -debug-types-section solution uses