search for: dwarfv4

..., resulting in a false dependence of CLANG/LLVM on entire generation phase of debug info for macros, even when they don't have to. - To worsen the problem even more, we have some DWARF forms sharing same encoding. Currently, we have 4-forms that share same encoding with previous DWARFv4. High Level Summary of Solution ======================== To deal with this and to facilitate addition of new future DWARF forms and other stuff, I propose following changes to be done: · Segregate CLANG entirely from macro debug info part. This has been done by introducing a new Generic Ma...

I think we have to be careful here. We might want flexibility to say "I want to use a specific class" without having to specify the exact DW_FORM. Sometimes, we might even end up in an ambiguous situation and not get the result we want. For example, in DWARFv4, the DW_AT_high_pc attribute has either a Constant or an Address class, which use completely different forms, but if we have just "Value: 0x1234", which is it? In DWARFv3, it is always an Address, if I remember correctly, so in that case, we might want our default to be "Address&quot...

...rse DWARF, even a >> little bit of it (only the first 4 bytes of a section to tell which >> version it is - first 12 if you want to be able to jump over >> contributions and check /all/ contributions coming from a given input >> object file (it might contain a combination of DWARFv4 and DWARFv5) >> and then the hairy uncertainty of which sections to check (do you >> check them all? well, all the ones with length prefixes that >> communicate DWARF32/64 - some sections don't >> (debug_ranges/loc/str/macro for instance, if I recall correctly)... >&g...

...awback in sorting, is the need to parse DWARF, even a little bit of it (only the first 4 bytes of a section to tell which version it is - first 12 if you want to be able to jump over contributions and check /all/ contributions coming from a given input object file (it might contain a combination of DWARFv4 and DWARFv5) and then the hairy uncertainty of which sections to check (do you check them all? well, all the ones with length prefixes that communicate DWARF32/64 - some sections don't (debug_ranges/loc/str/macro for instance, if I recall correctly)... and if something has some 4 and 5, does it...

...t; >> little bit of it (only the first 4 bytes of a section to tell which > >> version it is - first 12 if you want to be able to jump over > >> contributions and check /all/ contributions coming from a given input > >> object file (it might contain a combination of DWARFv4 and DWARFv5) > >> and then the hairy uncertainty of which sections to check (do you > >> check them all? well, all the ones with length prefixes that > >> communicate DWARF32/64 - some sections don't > >> (debug_ranges/loc/str/macro for instance, if I recall...

...little bit of it (only the first 4 bytes of a section to tell which >> >> version it is - first 12 if you want to be able to jump over >> >> contributions and check /all/ contributions coming from a given input >> >> object file (it might contain a combination of DWARFv4 and DWARFv5) >> >> and then the hairy uncertainty of which sections to check (do you >> >> check them all? well, all the ones with length prefixes that >> >> communicate DWARF32/64 - some sections don't >> >> (debug_ranges/loc/str/macro for instan...

...RFv5 does a pretty good job of reducing relocations (& reducing .o file size with Split DWARF) by allowing many uses of addresses to include some kind of address+offset (debug_rnglists and loclists allowing "base_address" then offset_pairs (an improvement over similar functionality in DWARFv4 because the offset pairs can be uleb encoded - so they can be quite compact)) But one place that DWARFv5 misses to reduce relocations further is direct addresses from debug_info, such as DW_AT_low_pc. For a while I've wondered if we could use an extension form for addr+offset, and I prototype...

...s the need to parse DWARF, even a little bit > of it (only the first 4 bytes of a section to tell which version it is - first 12 if you > want to be able to jump over contributions and check /all/ contributions > coming from a given input object file (it might contain a combination of > DWARFv4 and DWARFv5) and then the hairy uncertainty of which sections to > check (do you check them all? well, all the ones with length prefixes that > communicate DWARF32/64 - some sections don't > (debug_ranges/loc/str/macro for instance, if I recall correctly)... > and if something has s...

...ses down to, ideally, one address per section/indivisible chunk of machine code (per subsection in MachO, for instance) (whereas currently there are many addresses per section) > >> How do you figure the offset out? > > Label difference - same as is done for DW_AT_high_pc today in DWARFv4 and DWARFv5 in LLVM. high_pc currently uses the low_pc addresse to be relative to, in this proposed situation, we'd use a symbol that's in the first bit of debug info in the section (or subsection in MachO). So the low_pc of the subprogram/function, for instance, or if there are two functio...

...reducing relocations (& reducing .o file size with Split > > DWARF) by allowing many uses of addresses to include some kind of > > address+offset (debug_rnglists and loclists allowing "base_address" then > > offset_pairs (an improvement over similar functionality in DWARFv4 because > > the offset pairs can be uleb encoded - so they can be quite compact)) > > > > > > But one place that DWARFv5 misses to reduce relocations further is > > direct addresses from debug_info, such as DW_AT_low_pc. > > > > > > For a while I'...

...little bit of it (only the first 4 bytes of a section to tell which >> >> version it is - first 12 if you want to be able to jump over >> >> contributions and check /all/ contributions coming from a given input >> >> object file (it might contain a combination of DWARFv4 and DWARFv5) >> >> and then the hairy uncertainty of which sections to check (do you >> >> check them all? well, all the ones with length prefixes that >> >> communicate DWARF32/64 - some sections don't >> >> (debug_ranges/loc/str/macro for instan...

Hi Pavel, Thanks for your comments! On 5/21/20, Pavel Labath <pavel at labath.sk> wrote: > Hello Xing, > > I think the proposal looks very useful. I think it will be fairly tricky > to get all of the details right though. There is a lot of "inferring" > going on there, and getting that to work reliably and with predictable > results will need careful

...s the need to parse DWARF, even a > little bit of it (only the first 4 bytes of a section to tell which > version it is - first 12 if you want to be able to jump over > contributions and check /all/ contributions coming from a given input > object file (it might contain a combination of DWARFv4 and DWARFv5) > and then the hairy uncertainty of which sections to check (do you > check them all? well, all the ones with length prefixes that > communicate DWARF32/64 - some sections don't > (debug_ranges/loc/str/macro for instance, if I recall correctly)... > and if something...

...gt; good job of reducing relocations (& reducing .o file size with Split > DWARF) by allowing many uses of addresses to include some kind of > address+offset (debug_rnglists and loclists allowing "base_address" then > offset_pairs (an improvement over similar functionality in DWARFv4 because > the offset pairs can be uleb encoded - so they can be quite compact)) > > > > But one place that DWARFv5 misses to reduce relocations further is > direct addresses from debug_info, such as DW_AT_low_pc. > > > > For a while I've wondered if we could use an...

...tions combined with a .text mapping that starts in relative low addresses - premature debug_range termination with zero-length functions (Clang produces these with __builtin_unreachable or non-void return type functions without a return statement) New behavior: - -2 for DWARFv4 debug_loc, debug_ranges (-1 is a base address specifier there) - -1 elsewhere - linker flag to customize to other values if desired Known issues: - lldb's line table parsing can't handle -1 well at all (essentially unusable) - gdb's line table parsing ends up with di...

...n DWARF in general. It's only specified for CUs, but >> + // .eh_frame can appear without a .debug_info section. Follow the example of >> + // other tools (libdwarf) and extract this from the container (ObjectFile >> + // provides this information). This problem is fixed in DWARFv4 >> + // See this dwarf-discuss discussion for more details: >> + // http://lists.dwarfstd.org/htdig.cgi/dwarf-discuss-dwarfstd.org/2011-December/001173.html >> + DataExtractor debugFrameData(getDebugFrameSection(), isLittleEndian(), >> + getA...

This year Igor Kudrin put in a lot of work in enabling DWARF64 support in LLVM. At Facebook we are looking into it as one of the options for handling debug information over 4gigs in production environment. One concern is that due to mix of third party libraries and llvm compiled code the final library/binary will have a mix of CU that are DWARF32/64. This is supported by DWARF format. With this

...; > - premature debug_range termination with zero-length functions (Clang >> > produces these with __builtin_unreachable or non-void return >> >type functions >> > without a return statement) >> > >> >New behavior: >> > >> > - -2 for DWARFv4 debug_loc, debug_ranges (-1 is a base address specifier >> > there) >> > - -1 elsewhere >> > - linker flag to customize to other values if desired >> > >> >Known issues: >> > >> > - lldb's line table parsing can't handle -1 well...

...ctions (Clang >> >> > produces these with __builtin_unreachable or non-void return >> >> >type functions >> >> > without a return statement) >> >> > >> >> >New behavior: >> >> > >> >> > - -2 for DWARFv4 debug_loc, debug_ranges (-1 is a base address specifier >> >> > there) >> >> > - -1 elsewhere >> >> > - linker flag to customize to other values if desired >> >> > >> >> >Known issues: >> >> > >> >&gt...

...t; >> >> >type functions > > >> >> >> > without a return statement) > > >> >> >> > > > >> >> >> >New behavior: > > >> >> >> > > > >> >> >> > - -2 for DWARFv4 debug_loc, debug_ranges (-1 is a base > address specifier > > >> >> >> > there) > > >> >> >> > - -1 elsewhere > > >> >> >> > - linker flag to customize to other values if desired > > >> >> >>...