On Mon, Jan 27, 2025 at 3:17 AM Alan Maguire <alan.maguire@xxxxxxxxxx> wrote: > > On 26/01/2025 20:04, Cong Wang wrote: > > On Sat, Jan 25, 2025 at 8:55 PM Cong Wang <xiyou.wangcong@xxxxxxxxx> wrote: > >> > >> Hi Alan, > >> > >> On Tue, Dec 17, 2024 at 2:36 AM Alan Maguire <alan.maguire@xxxxxxxxxx> wrote: > >>> > >>> We use the DWARF location information to match a variable with its > >>> associated ELF section. In the case of per-CPU variables their > >>> ELF section address range starts at 0, so any 0 address variables will > >>> appear to belong in that ELF section. However, for "discard" sections > >>> DWARF encodes the associated variables with address location 0 so > >>> we need to double-check that address 0 variables really are in the > >>> associated section by checking the ELF symbol table. > >>> > >>> This resolves an issue exposed by CONFIG_DEBUG_FORCE_WEAK_PER_CPU=y > >>> kernel builds where __pcpu_* dummary variables in a .discard section > >>> get misclassified as belonging in the per-CPU variable section since > >>> they specify location address 0. > >> > >> It is _not_ your patch's fault, but I got this segfault which prevents me from > >> testing this patch. (It also happens after reverting your patch.) > > > > Never mind, I managed to workaround this issue by a clean build. > > > > And I tested your patch, it works for me with CONFIG_DEBUG_FORCE_WEAK_PER_CPU=y. > > > > Tested-by: Cong Wang <cong.wang@xxxxxxxxxxxxx> > > > > Thanks a lot! > > Thanks for verifying the fix! You didn't happen to get a coredump or > backtrace for the earlier segmentation fault by any chance? Just want to > make sure there aren't other issues lurking here. Thanks again! I didn't. I guess there was some mess in my build env, since a clean build just worked. Thanks!
