Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Sun, 16 Oct 2022 17:41:02 -0700
From:   Nathan Chancellor <nathan@kernel.org>
To:     Andrew Morton <akpm@linux-foundation.org>
Cc:     Masahiro Yamada <masahiroy@kernel.org>,
        Nick Desaulniers <ndesaulniers@google.com>,
        Tom Rix <trix@redhat.com>, Palmer Dabbelt <palmer@dabbelt.com>,
        Conor Dooley <conor@kernel.org>, linux-kbuild@vger.kernel.org,
        linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
        patches@lists.linux.dev, llvm@lists.linux.dev
Subject: Re: [PATCH v2] lib/Kconfig.debug: Add check for non-constant
 .{s,u}leb128 support to DWARF5
Message-ID: <Y0yknpUJn5K2uhw1@dev-arch.thelio-3990X>
References: <20221014204210.383380-1-nathan@kernel.org>
 <20221016172815.f5a5f1f86af7ff1937a2e273@linux-foundation.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20221016172815.f5a5f1f86af7ff1937a2e273@linux-foundation.org>
Precedence: bulk

Hi Andrew,

On Sun, Oct 16, 2022 at 05:28:15PM -0700, Andrew Morton wrote:
> On Fri, 14 Oct 2022 13:42:11 -0700 Nathan Chancellor <nathan@kernel.org> wrote:
> 
> > When building with a RISC-V kernel with DWARF5 debug info using clang
> > and the GNU assembler, several instances of the following error appear:
> > 
> >   /tmp/vgettimeofday-48aa35.s:2963: Error: non-constant .uleb128 is not supported
> 
> hm, which kernels want this?
> 
> I could merge it for 6.1, which seems suitable.  If we want it
> backported into earlier kernels then a Fixes: would be nice, to prevent
> it from being ported back further than necessary.

Masahiro took this for 6.1 via the kbuild tree, it is now in mainline as
commit 0a6de78cff60 ("lib/Kconfig.debug: Add check for non-constant
.{s,u}leb128 support to DWARF5"). It does need to go to stable but it
needs a few prerequisite changes to cover all cases and I did not want
to try and describe those dependencies in the patch itself. I should be
able to handle the backports manually tomorrow.

Cheers,
Nathan