On Tue, Feb 25, 2025 at 10:13 AM Josh Poimboeuf <jpoim...@kernel.org> wrote: > > On Tue, Feb 25, 2025 at 01:02:24AM +0000, Weinan Liu wrote: > > On Mon, Feb 10, 2025 at 12:30 AM Weinan Liu <wn...@google.com> wrote: > > > I already have a WIP patch to add sframe support to the kernel module. > > > However, it is not yet working. I had trouble unwinding frames for the > > > kernel module using the current algorithm. > > > > > > Indu has likely identified the issue and will be addressing it from the > > > toolchain side. > > > > > > https://sourceware.org/bugzilla/show_bug.cgi?id=32666 > > > > > > I have a working in progress patch that adds sframe support for kernel > > module. > > https://github.com/heuza/linux/tree/sframe_unwinder.rfc > > > > According to the sframe table values I got during runtime testing, looks > > like the offsets are not correct . > > > > When unwind symbols init_module(0xffff80007b155048) from the kernel > > module(livepatch-sample.ko), the start_address of the FDE entries in the > > sframe table of the kernel modules appear incorrect. > > For instance, the first FDE's start_addr is reported as -20564. Adding > > this offset to the module's sframe section address (0xffff80007b15a040) > > yields 0xffff80007b154fec, which is not within the livepatch-sample.ko > > memory region(It should be larger than 0xffff80007b155000). > > I assume kpatch create-diff-object needs to copy over a subset of the > .sframe section. Similar to what kpatch_regenerate_orc_sections() does.
You're right that we need to process the sframe section like what kpatch_regenerate_orc_sections() does when building livepatch by kpatch. However, livepatch-sample.ko is not generated by kpatch. It is built directly from samples/livepatch/livepatch-sample.c by gcc during the kernel build
