Make find_runtime_tools available for non-Chrome executables.

Make find_runtime_tools available for non-Chrome executables.

BUG=123750
TEST=None
NOTRY=True

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=271872

[Dai Mikurube (NOT FULLTIME), 2014-05-21 08:13:36]

Hoshi-san,

It'd make dmprof work for content_shell. Could you rubber-stamp it?

[hajimehoshi, 2014-05-21 08:21:40]

On 2014/05/21 08:13:36, Dai Mikurube wrote:
> Hoshi-san,
> 
> It'd make dmprof work for content_shell. Could you rubber-stamp it?

Thanks a lot!! lgtm

[Dai Mikurube (NOT FULLTIME), 2014-05-21 08:23:44]

The CQ bit was checked by dmikurube@chromium.org

[Dai Mikurube (NOT FULLTIME), 2014-05-21 08:23:48]

Thanks!

[commit-bot: I haz the power, 2014-05-21 08:25:16]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/dmikurube@chromium.org/299753007/1

[commit-bot: I haz the power, 2014-05-21 08:28:16]

Change committed as 271872

[wensheng, 2014-08-30 03:29:48]

wensheng.he@samsung.com changed reviewers:
+ wensheng.he@samsung.com

[wensheng, 2014-08-30 03:29:48]

https://codereview.chromium.org/299753007/diff/1/tools/linux/procfs.py
File tools/linux/procfs.py (right):

https://codereview.chromium.org/299753007/diff/1/tools/linux/procfs.py#newcod...
tools/linux/procfs.py:314:
r'\S+\.(so|dll|dylib|bundle)((\.\d+)+\w*(\.\d+){0,3})?')
Dmprof may not support content shell as the modification here, 
but when I just try to use dmprof in content shell and the result is that I
don't have the same problem (currently I still not merge the bug).
At last, I  find out the reason is that my path have the key word chrome:
/home/view/dtv_view/hewensheng/chrome37/src/out_type_nop/Release/content_shell
So I think this is not accurate for the matching rule for the pathname in
/proc/[pid]/maps. Better to add '$' in the RE here, I think.

[Dai Mikurube (NOT FULLTIME), 2014-09-02 15:11:15]

https://codereview.chromium.org/299753007/diff/1/tools/linux/procfs.py
File tools/linux/procfs.py (right):

https://codereview.chromium.org/299753007/diff/1/tools/linux/procfs.py#newcod...
tools/linux/procfs.py:314:
r'\S+\.(so|dll|dylib|bundle)((\.\d+)+\w*(\.\d+){0,3})?')
On 2014/08/30 03:29:48, wensheng.he wrote:
> Dmprof may not support content shell as the modification here, 
> but when I just try to use dmprof in content shell and the result is that I
> don't have the same problem (currently I still not merge the bug).
> At last, I  find out the reason is that my path have the key word chrome:
> /home/view/dtv_view/hewensheng/chrome37/src/out_type_nop/Release/content_shell
> So I think this is not accurate for the matching rule for the pathname in
> /proc/[pid]/maps. Better to add '$' in the RE here, I think.

Please take a look in prepare_symbol_info.py. It now accepts any file if the
file is executable. content_shell is used by this rule.

[wensheng, 2014-09-07 07:49:42]

On 2014/09/02 15:11:15, Dai Mikurube (NOT FULLTIME) wrote:
> https://codereview.chromium.org/299753007/diff/1/tools/linux/procfs.py
> File tools/linux/procfs.py (right):
> 
>
https://codereview.chromium.org/299753007/diff/1/tools/linux/procfs.py#newcod...
> tools/linux/procfs.py:314:
> r'\S+\.(so|dll|dylib|bundle)((\.\d+)+\w*(\.\d+){0,3})?')
> On 2014/08/30 03:29:48, wensheng.he wrote:
> > Dmprof may not support content shell as the modification here, 
> > but when I just try to use dmprof in content shell and the result is that I
> > don't have the same problem (currently I still not merge the bug).
> > At last, I  find out the reason is that my path have the key word chrome:
> >
/home/view/dtv_view/hewensheng/chrome37/src/out_type_nop/Release/content_shell
> > So I think this is not accurate for the matching rule for the pathname in
> > /proc/[pid]/maps. Better to add '$' in the RE here, I think.
> 
> Please take a look in prepare_symbol_info.py. It now accepts any file if the
> file is executable. content_shell is used by this rule.

Sorry, maybe my question is not clear.
The rule to matching the file extension is an absolute path, not exactly the
file name. 
So if the path before the file name already has the key word of the file
extension, e.x, "chrome" or "so",
it will still match the condition. This is not accurate, I think.
The solution I advise is to add '$' in the regular expression, so it will match
the file name exactly.