Re: [EXTERNAL] Re: DWARF Debug Info Relocations (.debug_str STRP references)

2020-11-30 Thread Mark Wielaard
Hi Bill, On Mon, Nov 30, 2020 at 10:22:34PM +, Bill Messmer wrote: > I'm still a bit confused here. And the reason I ask this is because > I open this particular vmlinux image with an OSS ELF/DWARF > library... which gives me the *WRONG* names for various DWARF DIEs. > I stepped through the

Re: DWARF64 gcc/clang flag discussion

2020-11-30 Thread Alexander Yermolovich via Gcc
From: David Blaikie Sent: Monday, November 30, 2020 12:09 PM To: Alexander Yermolovich Cc: Richard Biener ; Jakub Jelinek ; Mark Wielaard ; gcc@gcc.gnu.org ; ikud...@accesssoftek.com ; mask...@google.com Subject: Re: DWARF64 gcc/clang flag discussion On Mo

RE: [EXTERNAL] Re: DWARF Debug Info Relocations (.debug_str STRP references)

2020-11-30 Thread Bill Messmer via Gcc
Mark, Much appreciate the response. I'm still a bit confused here. And the reason I ask this is because I open this particular vmlinux image with an OSS ELF/DWARF library... which gives me the *WRONG* names for various DWARF DIEs. I stepped through the library... and the reason the names a

Re: DWARF64 gcc/clang flag discussion

2020-11-30 Thread Mark Wielaard
On Mon, Nov 30, 2020 at 07:35:36PM +, Alexander Yermolovich via Gcc wrote: > I guess discussion is from perspective of having both flags > gdwarf32/gdwarf64. In which case it's a valid question on whether > they should imply -g like -gdwarf-#. But can this be viewed as only > a -gdwarf64 flag,

Re: DWARF Debug Info Relocations (.debug_str STRP references)

2020-11-30 Thread Mark Wielaard
Hi Bill, On Mon, Nov 30, 2020 at 07:18:50PM +, Bill Messmer via Gcc wrote: > I am trying to understand something unexpected I am seeing in the relocations > placed into a compiled Linux kernel for the .debug_info section. Those > relocations seem to change the names of various entries in th

Re: DWARF64 gcc/clang flag discussion

2020-11-30 Thread David Blaikie via Gcc
On Mon, Nov 30, 2020 at 11:36 AM Alexander Yermolovich wrote: > Thank you David for driving the conversation, sorry I was on vacation. > All good - really appreciate everyone chipping in whenever/however they can! > > I guess discussion is from perspective of having both flags > gdwarf32/gdwar

Re: DWARF64 gcc/clang flag discussion

2020-11-30 Thread Fāng-ruì Sòng via Gcc
On Mon, Nov 30, 2020 at 11:36 AM Alexander Yermolovich wrote: > > Thank you David for driving the conversation, sorry I was on vacation. > > I guess discussion is from perspective of having both flags > gdwarf32/gdwarf64. In which case it's a valid question on whether they should > imply -g like

Re: DejaGnu diagnostics checking confused, possibly related to 'dg-line'?

2020-11-30 Thread Jeff Law via Gcc
On 11/24/20 6:16 AM, Thomas Schwinge wrote: > Hi! > > Ping. Anybody got an opinion on the approach we should take? Could we set warning_threshold to a value to inhibit this behavior completely.  It seems backwards to me that warnings have this effect. Jeff

Re: DWARF64 gcc/clang flag discussion

2020-11-30 Thread Alexander Yermolovich via Gcc
Thank you David for driving the conversation, sorry I was on vacation. I guess discussion is from perspective of having both flags gdwarf32/gdwarf64. In which case it's a valid question on whether they should imply -g like -gdwarf-#. But can this be viewed as only a -gdwarf64 flag, that is a qua

DWARF Debug Info Relocations (.debug_str STRP references)

2020-11-30 Thread Bill Messmer via Gcc
Hello! I am trying to understand something unexpected I am seeing in the relocations placed into a compiled Linux kernel for the .debug_info section. Those relocations seem to change the names of various entries in the debug info: [65] .debug_info PROGBITS

Re: Possible code to remove DECL_NONSHAREABLE?

2020-11-30 Thread Jeff Law via Gcc
On 11/27/20 5:47 AM, Matthew Malcomson via Gcc wrote: > Hi there, > > I was just looking through the history of how some code came about, > and get the impression that DECL_NONSHAREABLE was meant to be removed. > > It seems like it was added to solve PR49103, with the idea that it > could be rem

Re: [RFC] Increase libstdc++ line length to 100(?) columns

2020-11-30 Thread Michael Matz
Hello, On Mon, 30 Nov 2020, Allan Sandfeld Jensen wrote: > > > On Sonntag, 29. November 2020 18:38:15 CET Florian Weimer wrote: > > > > * Allan Sandfeld Jensen: > > > > > If you _do_ change it. I would suggest changing it to 120, which is > > > > > next > > > > > common step for a lot of C++ proj

Re: [RFC] Increase libstdc++ line length to 100(?) columns

2020-11-30 Thread Allan Sandfeld Jensen
On Montag, 30. November 2020 16:47:08 CET Michael Matz wrote: > Hello, > > On Sun, 29 Nov 2020, Allan Sandfeld Jensen wrote: > > On Sonntag, 29. November 2020 18:38:15 CET Florian Weimer wrote: > > > * Allan Sandfeld Jensen: > > > > If you _do_ change it. I would suggest changing it to 120, which

Re: [RFC] Increase libstdc++ line length to 100(?) columns

2020-11-30 Thread Michael Matz
Hello, On Sun, 29 Nov 2020, Allan Sandfeld Jensen wrote: > On Sonntag, 29. November 2020 18:38:15 CET Florian Weimer wrote: > > * Allan Sandfeld Jensen: > > > If you _do_ change it. I would suggest changing it to 120, which is next > > > common step for a lot of C++ projects. > > > > 120 can be