On Tue, Aug 25, 2020 at 6:05 AM Alexandre Oliva <ol...@adacore.com> wrote: > > On Aug 24, 2020, Jakub Jelinek <ja...@redhat.com> wrote: > > > On Mon, Aug 24, 2020 at 02:56:54PM +0200, Mark Wielaard wrote: > >> DWARF5 makes it possible to read loclists tables without consulting > >> the debuginfo tree by introducing a table header. Adding location views > >> breaks this (at least for binutils and elfutils). So don't enable > >> variable-location-views by default if DWARF5 or higher is selected. > > > This should be discussed with Alex, CCed. > > I'd say elfutils/binutils should just show .debug_loclists independent of > > .debug_info if there are no loc views and use .debug_info otherwise. > > I've suggested before that it made sense to me to start emitting > locviews when there were concrete plans to implement support for them in > debug info consumers. > > Without such plans, it would make more sense to just disable them > altogether. > > Now, if there are any such plans, it is disabling them for the default > debug format that doesn't make much sense to me; it would seem to make > more sense to adopt and promote the proposed extension, implemented in > =incompat5 in GCC, but it would need some implementation work in > consumers to at least ignore the extension. > > > Red Hat has had me involved in these efforts for over a decade, but I'm > not aware of its plans any more, and I don't know of anyone else driving > the implementation of locviews in consumers, so, given the little I > know, this patch seems like a timid step in a reasonable direction: > outputting locviews is no use if there are no consumers for it, more so > when they actively disturb existing standard-compliant consumers.
But then leaving it enabled by default but not with -gdwarf-5 looks odd and backward to me as well. If the consensus is there's no use then please disable them by default everywhere instead. Richard. > -- > Alexandre Oliva, happy hacker > https://FSFLA.org/blogs/lxo/ > Free Software Activist > GNU Toolchain Engineer
