[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZJXTwqZIkXLxXaSi@google.com>
Date: Fri, 23 Jun 2023 10:17:54 -0700
From: Nick Desaulniers <ndesaulniers@...gle.com>
To: Jisheng Zhang <jszhang@...nel.org>
Cc: Palmer Dabbelt <palmer@...belt.com>, bjorn@...nel.org,
Conor Dooley <conor@...nel.org>, jszhang@...nel.org,
llvm@...ts.linux.dev, Paul Walmsley <paul.walmsley@...ive.com>,
aou@...s.berkeley.edu, Arnd Bergmann <arnd@...db.de>,
linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org,
linux-arch@...r.kernel.org
Subject: Re: [PATCH v2 0/4] riscv: enable HAVE_LD_DEAD_CODE_DATA_ELIMINATION
On Thu, Jun 22, 2023 at 11:18:03PM +0000, Nathan Chancellor wrote:
> If you wanted to restrict it to just LD_IS_BFD in arch/riscv/Kconfig,
> that would be fine with me too.
>
> select HAVE_LD_DEAD_CODE_DATA_ELIMINATION if LD_IS_BFD
Hi Jisheng, would you mind sending a v3 with the attached patch applied
on top / at the end of your series?
>
> Nick said he would work on a report for the LLVM side, so as long as
> this issue is handled in some way to avoid regressing LLD builds until
> it is resolved, I don't think there is anything else for the kernel to
> do. We like to have breadcrumbs via issue links, not sure if the report
> will be internal to Google or on LLVM's issue tracker though;
> regardless, we will have to touch this block to add a version check
> later, at which point we can add a link to the fix in LLD.
https://github.com/ClangBuiltLinux/linux/issues/1881
View attachment "0001-riscv-disable-DEAD_CODE_ELIMINATION-for-LLD.patch" of type "text/x-diff" (1644 bytes)
Powered by blists - more mailing lists