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
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
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
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
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
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
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
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
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
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
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,
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
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
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
14 matches
Mail list logo
