gdb/scripts: Module symbol search paths
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
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?
Perhaps we ought to prefix our search path with
$(path_item)/lib/modules/uname -r
ST's C implementation of module support can be seen at:
They restrict the search paths, and parse expected lib/modules/{version}/ paths to ensure the correct modules are discovered.
--
Regards
Kieran
Hi Kieran,
Quoted 16 lines · Kieran Bingham
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_64loading @0xffffffffa0000000:/opt/root/ubuntu-vivid.x86_64/lib/modules/4.4.0+/extra/helloworld.ko
Quoted 7 lines
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.
Quoted 6 lines
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.
Jan
Quoted 17 lines
Perhaps we ought to prefix our search path with
$(path_item)/lib/modules/uname -rST's C implementation of module support can be seen at:
They restrict the search paths, and parse expected
lib/modules/{version}/paths to ensure the correct modules are discovered.--
RegardsKieran
Signature · 2 lines
Siemens AG, Corporate Technology, CT RDA ITP SES-DE Corporate Competence Center Embedded Linux
Quoted 34 lines · Jan Kiszka
Hi Kieran,
Quoted 16 lines · Kieran Bingham
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_64loading @0xffffffffa0000000:/opt/root/ubuntu-vivid.x86_64/lib/modules/4.4.0+/extra/helloworld.koQuoted 7 lines
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.koIf 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.Quoted 4 lines
Unfortunately I can't see any reference to a vfs path in:
print $lx_module("helloworld")
Quoted 7 lines
Quoted 2 lines
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.
Peter et al, do you have any opinion on this?
--
Kieran
Quoted 21 lines
Jan
Quoted 17 lines
Perhaps we ought to prefix our search path with
$(path_item)/lib/modules/uname -rST's C implementation of module support can be seen at:
They restrict the search paths, and parse expected
lib/modules/{version}/paths to ensure the correct modules are discovered.--
RegardsKieran
Quoted 50 lines · Kieran Bingham
Quoted 34 lines · Jan Kiszka
Hi Kieran,
Quoted 16 lines · Kieran Bingham
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_64loading @0xffffffffa0000000:/opt/root/ubuntu-vivid.x86_64/lib/modules/4.4.0+/extra/helloworld.koQuoted 7 lines
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.koIf 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.Quoted 4 lines
Unfortunately I can't see any reference to a vfs path in:
print $lx_module("helloworld")Quoted 7 lines
Quoted 2 lines
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.
Quoted 6 lines
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...
Jan
Signature · 2 lines
Siemens AG, Corporate Technology, CT RDA ITP SES-DE Corporate Competence Center Embedded Linux
Quoted 54 lines · Jan Kiszka
Quoted 53 lines · Kieran Bingham
Quoted 34 lines · Jan Kiszka
Hi Kieran,
Quoted 16 lines · Kieran Bingham
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_64loading @0xffffffffa0000000:/opt/root/ubuntu-vivid.x86_64/lib/modules/4.4.0+/extra/helloworld.koQuoted 7 lines
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.koIf 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.Quoted 4 lines
Unfortunately I can't see any reference to a vfs path in:
print $lx_module("helloworld")Quoted 7 lines
Quoted 2 lines
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 :)
Quoted 7 lines
Quoted 3 lines
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
Quoted 3 lines
Jan