Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934095AbcCNLAr (ORCPT ); Mon, 14 Mar 2016 07:00:47 -0400 Received: from mail-wm0-f45.google.com ([74.125.82.45]:36526 "EHLO mail-wm0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752381AbcCNLAj (ORCPT ); Mon, 14 Mar 2016 07:00:39 -0400 Subject: Re: gdb/scripts: Module symbol search paths To: Jan Kiszka , Peter Griffin References: <56E69067.1020909@linaro.org> <56E69438.3030407@siemens.com> <56E696F7.5070100@linaro.org> <56E6989E.6080300@siemens.com> Cc: Lee Jones , Maxime Coquelin , Russell Wayman , Linux Kernel From: Kieran Bingham Message-ID: <56E699D4.50200@linaro.org> Date: Mon, 14 Mar 2016 11:00:36 +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: <56E6989E.6080300@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: 2824 Lines: 75 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 >