Re: Issue using faddr2line on kernel modules

[Josh Poimboeuf]

On Wed, Jan 19, 2022 at 09:27:18AM +0530, Kaiwan N Billimoria wrote:
> On Tue, Jan 18, 2022 at 11:22 PM Josh Poimboeuf <jpoimboe@xxxxxxxxxx> wrote:
> >
> > On Tue, Jan 18, 2022 at 08:10:28AM +0530, Kaiwan N Billimoria wrote:
> > > Hi Josh,
> > >
> > > Actually your first patch - the one you mentioned had other issues -
> > > worked perfectly when applied:
> > >
> > > scripts/faddr2line ./oops_tryv2.ko do_the_work+0x16f/0x194
> > > do_the_work+0x16f/0x0000000000000194:
> > > do_the_work at <...>/oops_tryv2/oops_tryv2.c:62
> > >
> > > The second one still failed in the same manner:
> > >
> > > scripts/faddr2line ./oops_tryv2.ko do_the_work+0x16f/0x194
> > > bad symbol size: base: 0x0000000000000000 end: 0x0000000000000000
> > >
> > > So, is it possible to fixup issues with the first version?
> > > What are these issues?
> >
> > The first patch basically reverts the fix in commit efdb4167e676
> > ("scripts/faddr2line: Fix "size mismatch" error").  That would be nice
> > as it's simpler and more robust, but unfortunately it would cause a lot
> > of "size mismatch" errors with vmlinux symbols.
> 
> I see... if it comes to it, could there be a workaround where the
> script detects a vmlinux image and works in a given manner,
> else in this manner for other images - in effect, for modules?

I think I misspoke about the vmlinux behavior being different, so I
don't think that would work.

> > Can you give the output of 'nm -n ./oops_tryv2.ko'?  There must be some
> > text symbol immediately after the do_the_work() symbol which is either
> > out of order, or part of another section.
> >
> > Is do_the_work() in the .text section?
> Yes...
> Here's the output I get:
> 
> $ nm -n ./oops_tryv2.ko |grep -C5 do_the_work
> 0000000000000000 r __func__.24215
> 0000000000000000 r __param_bug_in_workq
> 0000000000000000 D __this_module
> 0000000000000000 r _note_7
> 0000000000000000 T cleanup_module
> 0000000000000000 t do_the_work
> 0000000000000000 t do_the_work.cold
> 0000000000000000 b gctx
> 0000000000000000 T init_module
> 0000000000000000 t try_oops_exit
> 0000000000000000 t try_oops_init
> 0000000000000008 b t1
> $
> 
> BTW, here's the code:
> https://github.com/PacktPublishing/Linux-Kernel-Debugging/tree/main/ch7/oops_tryv2

Ok, it looks like the symbols aren't sorted like the code expects.  I
need to do a more robust fix.

-- 
Josh