This is the mail archive of the
elfutils-devel@sourceware.org
mailing list for the elfutils project.
Re: Fwd: [PATCH 0/3] perf tools: Add libdw DWARF post unwind support for ARM64
- From: Jean Pihet <jean dot pihet at linaro dot org>
- To: elfutils-devel at lists dot fedorahosted dot org
- Date: Fri, 21 Mar 2014 15:55:05 +0100
- Subject: Re: Fwd: [PATCH 0/3] perf tools: Add libdw DWARF post unwind support for ARM64
Hi Mark,
On 19 March 2014 15:09, Mark Wielaard <mjw@redhat.com> wrote:
> Hi Jean,
>
> On Wed, 2014-03-19 at 11:58 +0100, Jean Pihet wrote:
>> On 19 March 2014 11:46, Mark Wielaard <mjw@redhat.com> wrote:
>> Do you have an idea what/where to check for libdw compat support? I
>> just quickly browsed through the code and found the uses of the
>> ELFCLASS32/ELFCLASS64 macros interesting.
>
> In theory it should "just work" assuming arm32 as native arch works.
> Normally elfutils/libdwfl uses the backend that matches the ELF
> header/EM value used. The only issue is that for arm32 only .debug_frame
> is supported and not EXIDX tables (as .eh_frame isn't used on arm32).
> But I believe that isn't an issue in your case because you require the
> debuginfo to be available.
Yes. The test binaries do have the dwarf info available. The ELF
headers show different word sizes.
>
> If you were using the mjw/aarch64-unwind branch you might have missed
> various patches for arm32 support since that branch was fairly old. I
> have rebased the branch on current master now.
Thanks, I am using the rebased branch right now.
>
>> Do you need testing etc. in order to be able to merge the aarch64
>> branch? Please let me know!
>
> The system I am testing on is missing various glibc fixes, in particular
> https://sourceware.org/bugzilla/show_bug.cgi?id=16169 and gcc doesn't
> use -fasynchronous-unwind-tables by default. So the make check results
> are not reliable for me.
>
> If you can run make check on the rebased branch on your setup that would
> be helpful. Ideally all tests PASS. If not, the output of
> tests/test-suite.log would be interesting.
The tests are running since a while now (>12hours!) and it seems that
the backtrace test is taking ages to complete.
Here are the test current results, I do not have any log file yet.
PASS: run-arextract.sh
PASS: run-arsymtest.sh
PASS: newfile
PASS: test-nlist
PASS: update1
PASS: update2
PASS: update3
PASS: update4
PASS: run-show-die-info.sh
PASS: run-get-files.sh
PASS: run-get-lines.sh
PASS: run-get-pubnames.sh
PASS: run-get-aranges.sh
PASS: run-allfcts.sh
PASS: run-show-abbrev.sh
PASS: run-line2addr.sh
PASS: hash
PASS: newscn
PASS: run-strip-test.sh
PASS: run-strip-test2.sh
PASS: run-strip-test3.sh
PASS: run-strip-test4.sh
PASS: run-strip-test5.sh
PASS: run-strip-test6.sh
PASS: run-strip-test7.sh
PASS: run-strip-test8.sh
PASS: run-strip-groups.sh
PASS: run-strip-reloc.sh
PASS: run-unstrip-test.sh
PASS: run-unstrip-test2.sh
PASS: run-unstrip-M.sh
PASS: run-ecp-test.sh
PASS: run-ecp-test2.sh
PASS: run-alldts.sh
PASS: run-elflint-test.sh
PASS: run-elflint-self.sh
PASS: run-ranlib-test.sh
PASS: run-ranlib-test2.sh
PASS: run-ranlib-test3.sh
PASS: run-ranlib-test4.sh
PASS: run-addrscopes.sh
PASS: run-strings-test.sh
PASS: run-funcscopes.sh
PASS: run-find-prologues.sh
PASS: run-allregs.sh
PASS: run-addrcfi.sh
PASS: run-nm-self.sh
PASS: run-readelf-self.sh
PASS: run-readelf-test1.sh
PASS: run-readelf-test2.sh
PASS: run-readelf-test3.sh
PASS: run-readelf-test4.sh
PASS: run-readelf-twofiles.sh
PASS: run-readelf-macro.sh
PASS: run-readelf-loc.sh
PASS: run-readelf-aranges.sh
PASS: run-readelf-line.sh
FAIL: run-native-test.sh
PASS: run-bug1-test.sh
PASS: dwfl-bug-addr-overflow
PASS: run-addrname-test.sh
PASS: dwfl-bug-fd-leak
PASS: dwfl-bug-report
PASS: run-dwfl-bug-offline-rel.sh
PASS: run-dwfl-addr-sect.sh
PASS: run-disasm-x86.sh
PASS: run-disasm-x86-64.sh
PASS: run-early-offscn.sh
PASS: run-dwarf-getmacros.sh
PASS: run-test-flag-nobits.sh
PASS: run-prelink-addr-test.sh
PASS: run-dwarf-getstring.sh
PASS: run-rerequest_tag.sh
PASS: run-typeiter.sh
PASS: run-readelf-d.sh
PASS: run-readelf-gdb_index.sh
PASS: run-unstrip-n.sh
PASS: run-low_high_pc.sh
PASS: run-macro-test.sh
PASS: run-elf_cntl_gelf_getshdr.sh
PASS: run-test-archive64.sh
PASS: run-readelf-vmcoreinfo.sh
PASS: run-readelf-mixed-corenote.sh
PASS: run-dwfllines.sh
PASS: run-dwfl-report-elf-align.sh
PASS: run-addr2line-test.sh
PASS: run-addr2line-i-test.sh
PASS: run-varlocs.sh
PASS: run-funcretval.sh
About unwinding, the AARCH64 dwarf unwinding using 'perf report' is ok:
# Overhead Command Shared Object
# ........ ............ ...................... ..............................
#
97.79% stress_bt_v8 stress_bt_v8 [.] foo_128
|
--- foo_128
|
|--99.37%-- foo_127
| |
| |--99.31%-- foo_126
| | |
| | |--99.35%-- foo_125
...
| | |
| | --0.65%-- bar
| | doit
| | main
| | 0x7f94cdb944
| | _start
| | 0x7fda172dcb
| |
| --0.69%-- bar
| doit
| main
| 0x7f94cdb944
| _start
| 0x7fda172dcb
|
--0.63%-- bar
doit
main
0x7f94cdb944
_start
0x7fda172dcb
0.16% stress_bt_v8 [kernel.kallsyms] [k] __do_softirq
|
--- __do_softirq
irq_exit
handle_IRQ
gic_handle_irq
|
|--93.92%-- el0_irq_naked
| |
| |--96.77%-- foo_128
| | foo_127
| | foo_126
| | foo_125
| | foo_124
| | foo_123
...
But not the compat mode (stress_bt_v7_static is a statically built
ARMv7 binary):
# Overhead Command Shared Object
# ........ ............... ................... ..............................
#
98.02% stress_bt_v7_st stress_bt_v7_static [.] foo_128
0.25% stress_bt_v7_st [vectors] [.] 0x00000000ffff0fc0
0.13% stress_bt_v7_st [kernel.kallsyms] [k] put_nfs_open_context
|
--- put_nfs_open_context
nfs_free_request
nfs_release_request
...
>
> Thanks,
>
> Mark
>
I let you know as soon as I have more test results.
Thanks,
Jean