Debug link crc values is strored after null terminated string in 4
aligned offset. But sysprof was only taking into accoutn alignment
that made elf parser read wrong crc from the debug link string.
Fix is simple check for string length and adding the length to offset
before alignment.
Signed-off-by: Pauli Nieminen <suokkos@gmail.com>
Linux kernel version received bump to 3.0 that causes configure to
complain about older kernel. To avoid the warning configure needs to
check major and minor versions before micro.
Signed-off-by: Pauli Nieminen <suokkos@gmail.com>
__ppc__ isn't defined here on Debian powerpc. Grepping through the headers
installed in /usr/include, there are a few references to __ppc__ and
__ppc64__, but I suspect they're for other OSs.
Signed-off-by: Michel Dänzer <michel@daenzer.net>
A few commits ago, an attempt to speed the map look up was done.
Unfortunatly, it was missing the case where you actually hit the speed
up (once the map is the first element of the array, you never return
it).
So, make sure that if i is 0, you return the first element of array,
while still doing the array reordering is i > 0.
perf lets you decide to only get events that concerns a single process
and thus make sysprof profile this process instead of the whole system
(it can happen that you don't really care about other processes that are
just then noise).
As a side effect, this allows sysprof to not run as root if you have the
rights on the process you want to profile.
It has issues on various architectures, such as ARM, and there was
never any guarantee that it would actually work. So since we'd need
fallback code anyway, and the main point of it was simplifying the
code, just get rid of it and handle the overflow conditions manually.
Currently, sysprof hardwires the syscall number of
__NR_perf_counter_open. That's all very well, except... like other
syscall numbers, it varies per-arch. With a few exceptions
(e.g. sparc64), it even varies between 32-bit and 64-bit x86 arches.
This patch provides the defines for every number I could see assigned
in git trunk right now, with the exception of some of the ARM ones, where
I couldn't see how to differentiate between the various sorts of ARM to
figure out what the syscall base was. For those, let's wait for libc to
catch up.
The only arch I've been unable even to guess at is the very new S-Core,
which is the only user so far of the generic syscall table in
<include/asm-generic>. This specifies a value of 241, but I can't hook
it up because I can't find an S-Core toolchain anywhere so I don't know
what #define to check for, and googling gives no clues.
Only tested on x86-64 (where it now works) so there may be all sorts of
bugs in the rest of it (well, in the #defines anyway, though most were
checked against GCC trunk).
