linux-kernel - mapping instructions to dynamic languages like java, python, ruby

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 22 Apr 2014 14:03:05 -0400
From:	Don Zickus <dzickus@...hat.com>
To:	peterz@...radead.org, acme@...hat.com, jolsa@...hat.com,
	namhyung@...nel.org
Cc:	linux-kernel@...r.kernel.org, eranian@...gle.com,
	andi@...stfloor.org, wcohen@...hat.com
Subject: mapping instructions to dynamic languages like java, python, ruby

Hi,

I was discussing recently with Will Cohen about how to get perf to
understand dynamic languages (java, python, ruby) better.  Currently, perf
samples and address, stores it in a mmap region (from the kernel side),
the mmap region is read (from user side async) and stored in a file.

During 'perf report' those instruction addresses are looked up in the
dwarf table?? of the binary they were mapped to, to resolve their symbols.

This works great for statically compiled binaries (like C), where the
addresses stay the same during each run of the binary.

However, for dynamic languages like java, python, ruby not only do those
addresses change each run of the binary, those address can change
_during_ the execution of the binary.  As a result the normal perf
collection method fails.

Oprofile has a mechanism to work around this, by creating a debug library
for java that records class information.  This library is linked?? during
the initial execution of the java program and all its symbol info is
recorded in a temp file.  During post-processing this temp file is read
back in and symbol info is obtained.

However, this approach is java specific and only works for programs that
initially start with it (can not attach to running programs).

Thoughts have come up about using a SIGPROF from the kernel to signal the
userspace interpreters to dump information to a temp file that can be used
later during post-processing.

Does anyone have any thoughts or experience on this?

Cheers,
Don

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/