Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755193AbcCNKsf (ORCPT ); Mon, 14 Mar 2016 06:48:35 -0400 Received: from mail-wm0-f43.google.com ([74.125.82.43]:32912 "EHLO mail-wm0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753943AbcCNKsZ (ORCPT ); Mon, 14 Mar 2016 06:48:25 -0400 Subject: Re: gdb/scripts: Module symbol search paths To: Jan Kiszka , Peter Griffin References: <56E69067.1020909@linaro.org> <56E69438.3030407@siemens.com> Cc: Lee Jones , Maxime Coquelin , Russell Wayman , Linux Kernel From: Kieran Bingham Message-ID: <56E696F7.5070100@linaro.org> Date: Mon, 14 Mar 2016 10:48:23 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56E69438.3030407@siemens.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2682 Lines: 83 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. Peter et al, do you have any opinion on this? -- Kieran > Jan > >> >> 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: >> >> https://git.linaro.org/people/kieran.bingham/binutils-gdb.git/blob/e30a18cf086bd02c4ebb57f6f783fe2ad4af9c84:/gdb/stlinux/lkd-modules.c >> >> They restrict the search paths, and parse expected >> lib/modules/{version}/ paths to ensure the correct modules are discovered. >> >> -- >> Regards >> >> Kieran >> > >