Re: gdb/scripts: Module symbol search paths

[Kieran Bingham]

On 14/03/16 10:55, Jan Kiszka wrote:
> On 2016-03-14 11:48, Kieran Bingham wrote:
>> On 14/03/16 10:36, Jan Kiszka wrote:
>>> Hi Kieran,
>>>
>>> On 2016-03-14 11:20, Kieran Bingham wrote:
>>>> Hi Jan,
>>>>
>>>> Whilst testing the modules update patch you sent, I discovered (due to
>>>> having rebased to v4.5) that the module search path will end up picking
>>>> an incorrect version of the .ko file if an earlier version exists.:
>>>>
>>>>
>>>> (gdb) lx-symbols /opt/root/ubuntu-vivid.x86_64
>>>> loading vmlinux
>>>> (gdb) c
>>>> Continuing.
>>>> 	< load module helloworld.ko on target >
>>>> scanning for modules in /opt/root/ubuntu-vivid.x86_64
>>>> loading @0xffffffffa0000000:
>>>> /opt/root/ubuntu-vivid.x86_64/lib/modules/4.4.0+/extra/helloworld.ko
>>>>
>>>> Looking at the filesystem layout:
>>>>
>>>> kbingham@CookieMonster:~$ sudo find /opt/root/ubuntu-vivid.x86_64/ -name
>>>> helloworld.ko
>>>> /opt/root/ubuntu-vivid.x86_64/lib/modules/4.4.0+/extra/helloworld.ko
>>>> /opt/root/ubuntu-vivid.x86_64/lib/modules/4.5.0+/extra/helloworld.ko
>>>>
>>>
>>> If there are multiple sets of modules underneath a path, you have to be
>>> more precise, /opt/root/ubuntu-vivid.x86_64/lib/modules/4.5.0+ in this case.
>>>
>>>>
>>>> Unfortunately I can't see any reference to a vfs path in:
>>>>  print $lx_module("helloworld")
>>>>
>>>> So we can't retrieve the exact path location from the kernel information
>>>> Have you experienced this issue?
>>>
>>> No, because I'm always using lx-symbols against the build output, not
>>> against installed modules. But even then, see above, I don't see a
>>> problem is the path is properly specified.
>>>
>>
>> Ok, I see. I guess it's just a different use-case. ST had this factored
>> out so that the user did not have to do much other than specify the root
>> path. And in fact, the 'user' didn't do this as it was pre-set.
>>
>> I had even toyed with the idea that we could parse the commandline - and
>> if we detect an nfsroot, automatically provide that on the search path.
>>
>> Perhaps we'll put this on the to-think-about stack for now then on this
>> side :)
>>
>> Specifying the full path to modules isn't an unreasonable solution IMO,
>> so it will just come down to a user-experience thing. The automatic
>> detection could just be classed as a nice feature for the future perhaps.
> 
> If you wanna do version matching, you could parse the module header and
> filter out everything that's incompatible. But then I'm afraid of the
> loading time...

Interesting alternative. I guess this parsing would only occur on files
after a filename match, so I don't see it as being too intrusive.
Perhaps something to test and measure later, and would need testing on a
large number of modules (with a large number of false positives to match
against).

--
Kieran

> 
> Jan
>