[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200611215227.GB3924125@rani.riverdale.lan>
Date: Thu, 11 Jun 2020 17:52:27 -0400
From: Arvind Sankar <nivedita@...m.mit.edu>
To: Nick Desaulniers <ndesaulniers@...gle.com>
Cc: Arvind Sankar <nivedita@...m.mit.edu>,
Masahiro Yamada <masahiroy@...nel.org>,
Fangrui Song <maskray@...gle.com>,
Rong Chen <rong.a.chen@...el.com>,
kernel test robot <lkp@...el.com>, kbuild-all@...ts.01.org,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] Makefile: Improve compressed debug info support detection
On Thu, Jun 11, 2020 at 02:09:21PM -0700, Nick Desaulniers wrote:
> On Wed, Jun 10, 2020 at 4:30 PM Arvind Sankar <nivedita@...m.mit.edu> wrote:
> >
> > Yes, the gcc driver reports an error when deciding what to pass to the
> > assembler for -gz=zlib, if it was configured with a linker that does not
> > support the flag. It's even more weird actually -- if it was configured
> > with a linker that supports the flag but an assembler that doesn't, it
> > will silently eat the flag when calling the assembler. At least that
> > won't break anything, though none of the .o files will be compressed.
>
> Not sure whether we'd like to prevent the option from being selectable
> in that case, or just to silently not compress the debug info. Given
> that the compression is an optimization, it doesn't hurt to silently
> not do it, but it would be nice to notify the user their toolchain may
> have been misconfigured. Though another part of me feels "garbage in,
> garbage out."
>
I don't think it's worth trying to detect it -- I can see it in the
source code, but it should be highly unlikely for a gcc to be configured
this way. Btw, it looks like if you configure gcc with LLD, it will
enable this option only because it thinks that "LLD 11.0.0 (compatible
with GNU linkers)" is GNU LD version 11, which is bigger than 2. Is that
intentional :)
> > No, as-option does invoke the assembler. The problem here is that with
> > -Wa, the option is only seen by the assembler, not the gcc driver. So it
> > will succeed because the assembler supports it, but it will not test
> > whether the gcc driver also supports it.
>
> ^ Those 2 last sentences should go in the commit message, as the
> current form doesn't allude to that.
Ok.
>
> Reviewed-by: Nick Desaulniers <ndesaulniers@...gle.com>
>
Powered by blists - more mailing lists