Some backtrace/probefunc notes

[Mark Wielaard <mjw at redhat dot com>]

Hi,

I added an early warning in the translator for PR10272, backtraces fail
with 32-on-64 executables.

commit 081b45d1a43b5b9ef936f5e40ff5cc26a754d95b
Author: Mark Wielaard <mjw@redhat.com>
Date:   Sat Nov 17 22:34:04 2012 +0100

  PR10272 Warn if we will be unable to generate user backtrace for 32-on-64.
   
  Deduce the kernel ELF class from the kernel normalized machine architecture
  and warn if it is different from the module ELF class (except for 32-bit
  vdso). Don't generate unwind tables for "wrong class" modules.

Of course it would be better to just fix that bug. So if anybody has some
time please have a go at it :)

While testing that I noticed that some scripts I didn't expect gave the
warning. That was because probefunc() (cleverly) uses [u]stack(0) to
get the current pc address. But we have (a slightly less clever)
[u]addr() function to get at the current pc address for the probe. This
seems a little more efficient, so I used that instead:

commit 7b73b8731aca120b5806b1739a5b2b39e4ca6ddd
Author: Mark Wielaard <mjw@redhat.com>
Date:   Sun Nov 18 22:29:49 2012 +0100

  probefunc(): Use [u]addr() instead of [u]stack(0).
   
  The result is the same, but the use of [u]stack(0) triggers the inclusion
  of unwind tables (even though there is literally zero unwinding going on).

I am seeing one related testsuite failure:
FAIL: probefunc:kernel.function("context_switch").inline shutdown (eof)
This happens with both stack(0) and addr() usage in probefunc().
The reason is that we now see the name of the function where this gets
inlined, not the inlined function name itself. With the old implementation
of probefunc() it would get the name from the actual probe string, so it
would know what the original probe function name was. Should this test be
changed?

Thanks,

Mark