2020-07-27 14:28:24

by Kieran Bingham

[permalink] [raw]
Subject: Re: [PATCH 4.19 42/86] scripts/gdb: fix lx-symbols gdb.error while loading modules

Hi Greg, Sasha,

On 27/07/2020 15:04, Greg Kroah-Hartman wrote:
> From: Stefano Garzarella <[email protected]>
>
> [ Upstream commit 7359608a271ce81803de148befefd309baf88c76 ]
>
> Commit ed66f991bb19 ("module: Refactor section attr into bin attribute")
> removed the 'name' field from 'struct module_sect_attr' triggering the
> following error when invoking lx-symbols:


Has ed66f991bb19 ("module: Refactor section attr into bin attribute")
been backported to 4.19? It doesn't /sound/ like something that would
require backporting unless something else depended up on it, but if it
hasn't been ... then *this* patch shouldn't be either...

Same for 5.4, and 5.7 that's just come in.

This patch will 'apply' cleanly, and not hit any compilation errors, as
it only changes python code... so my reason to highlight is in case some
automated system picked it up based on those assumptions.

If ed66f991bb19 has also been backported, then I'm sorry for the noise ;-)

--
Kieran



>
> (gdb) lx-symbols
> loading vmlinux
> scanning for modules in linux/build
> loading @0xffffffffc014f000: linux/build/drivers/net/tun.ko
> Python Exception <class 'gdb.error'> There is no member named name.:
> Error occurred in Python: There is no member named name.
>
> This patch fixes the issue taking the module name from the 'struct
> attribute'.
>
> Fixes: ed66f991bb19 ("module: Refactor section attr into bin attribute")
> Signed-off-by: Stefano Garzarella <[email protected]>
> Signed-off-by: Andrew Morton <[email protected]>
> Reviewed-by: Jan Kiszka <[email protected]>
> Reviewed-by: Kieran Bingham <[email protected]>
> Link: http://lkml.kernel.org/r/[email protected]
> Signed-off-by: Linus Torvalds <[email protected]>
> Signed-off-by: Sasha Levin <[email protected]>
> ---
> scripts/gdb/linux/symbols.py | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/scripts/gdb/linux/symbols.py b/scripts/gdb/linux/symbols.py
> index 4644f1a83b578..aa4f87e3ddb12 100644
> --- a/scripts/gdb/linux/symbols.py
> +++ b/scripts/gdb/linux/symbols.py
> @@ -96,7 +96,7 @@ lx-symbols command."""
> return ""
> attrs = sect_attrs['attrs']
> section_name_to_address = {
> - attrs[n]['name'].string(): attrs[n]['address']
> + attrs[n]['battr']['attr']['name'].string(): attrs[n]['address']
> for n in range(int(sect_attrs['nsections']))}
> args = []
> for section_name in [".data", ".data..read_mostly", ".rodata", ".bss",
>


--
--
Kieran


2020-07-27 14:39:02

by Stefano Garzarella

[permalink] [raw]
Subject: Re: [PATCH 4.19 42/86] scripts/gdb: fix lx-symbols gdb.error while loading modules

On Mon, Jul 27, 2020 at 03:26:42PM +0100, Kieran Bingham wrote:
> Hi Greg, Sasha,
>
> On 27/07/2020 15:04, Greg Kroah-Hartman wrote:
> > From: Stefano Garzarella <[email protected]>
> >
> > [ Upstream commit 7359608a271ce81803de148befefd309baf88c76 ]
> >
> > Commit ed66f991bb19 ("module: Refactor section attr into bin attribute")
> > removed the 'name' field from 'struct module_sect_attr' triggering the
> > following error when invoking lx-symbols:
>
>
> Has ed66f991bb19 ("module: Refactor section attr into bin attribute")
> been backported to 4.19? It doesn't /sound/ like something that would
> require backporting unless something else depended up on it, but if it
> hasn't been ... then *this* patch shouldn't be either...
>
> Same for 5.4, and 5.7 that's just come in.
>
> This patch will 'apply' cleanly, and not hit any compilation errors, as
> it only changes python code... so my reason to highlight is in case some
> automated system picked it up based on those assumptions.
>
> If ed66f991bb19 has also been backported, then I'm sorry for the noise ;-)
>

I had the same doubt, but I just saw that ed66f991bb19 was backported to
the stable branches (4.19, 5.4 and 5.7), so I think this backport is
correct.

Thanks,
Stefano

2020-07-27 14:41:45

by Kieran Bingham

[permalink] [raw]
Subject: Re: [PATCH 4.19 42/86] scripts/gdb: fix lx-symbols gdb.error while loading modules

Hi Stefano,

On 27/07/2020 15:37, Stefano Garzarella wrote:
> On Mon, Jul 27, 2020 at 03:26:42PM +0100, Kieran Bingham wrote:
>> Hi Greg, Sasha,
>>
>> On 27/07/2020 15:04, Greg Kroah-Hartman wrote:
>>> From: Stefano Garzarella <[email protected]>
>>>
>>> [ Upstream commit 7359608a271ce81803de148befefd309baf88c76 ]
>>>
>>> Commit ed66f991bb19 ("module: Refactor section attr into bin attribute")
>>> removed the 'name' field from 'struct module_sect_attr' triggering the
>>> following error when invoking lx-symbols:
>>
>>
>> Has ed66f991bb19 ("module: Refactor section attr into bin attribute")
>> been backported to 4.19? It doesn't /sound/ like something that would
>> require backporting unless something else depended up on it, but if it
>> hasn't been ... then *this* patch shouldn't be either...
>>
>> Same for 5.4, and 5.7 that's just come in.
>>
>> This patch will 'apply' cleanly, and not hit any compilation errors, as
>> it only changes python code... so my reason to highlight is in case some
>> automated system picked it up based on those assumptions.
>>
>> If ed66f991bb19 has also been backported, then I'm sorry for the noise ;-)
>>
>
> I had the same doubt, but I just saw that ed66f991bb19 was backported to
> the stable branches (4.19, 5.4 and 5.7), so I think this backport is> correct.

Perfect, thanks for confirming.

--
Kieran

2020-07-27 18:58:39

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH 4.19 42/86] scripts/gdb: fix lx-symbols gdb.error while loading modules

On Mon, Jul 27, 2020 at 03:26:42PM +0100, Kieran Bingham wrote:
> Hi Greg, Sasha,
>
> On 27/07/2020 15:04, Greg Kroah-Hartman wrote:
> > From: Stefano Garzarella <[email protected]>
> >
> > [ Upstream commit 7359608a271ce81803de148befefd309baf88c76 ]
> >
> > Commit ed66f991bb19 ("module: Refactor section attr into bin attribute")
> > removed the 'name' field from 'struct module_sect_attr' triggering the
> > following error when invoking lx-symbols:
>
>
> Has ed66f991bb19 ("module: Refactor section attr into bin attribute")
> been backported to 4.19? It doesn't /sound/ like something that would
> require backporting unless something else depended up on it, but if it
> hasn't been ... then *this* patch shouldn't be either...

It was released in 4.19.133, 5.4.52, and 5.7.9.

> Same for 5.4, and 5.7 that's just come in.
>
> This patch will 'apply' cleanly, and not hit any compilation errors, as
> it only changes python code... so my reason to highlight is in case some
> automated system picked it up based on those assumptions.
>
> If ed66f991bb19 has also been backported, then I'm sorry for the noise ;-)

It was, but thanks for the review!

greg k-h