Hi Sukadev, On Wed, 29 Oct 2014 14:26:20 -0700, Sukadev Bhattiprolu wrote: > Namhyung Kim [namhy...@kernel.org] wrote: > | I don't know how dwfl_report_offline() can make it to find out a mod > | from pc as it's an (loaded) virtual address. Maybe I miss something or > | is your dso's are prelinked? > > Scratching my head on this and a related issue. > > The code seems to work consistently on Fedora20 and we recently noticed > that it does not work on RHEL7. Maybe related to the issue you point out. > > On Fedora20 objdump -D /usr/lib64/libc-2.18.so shows something like this: > > 00000080a7be3bf0 <.__random>: > 80a7be3bf0: 7c 08 02 a6 mflr r0 > 80a7be3bf4: fb e1 ff f8 std r31,-8(r1) > 80a7be3bf8: 60 00 00 00 nop > 80a7be3bfc: 39 00 00 01 li r8,1 > 80a7be3c00: 3b e2 9a f0 addi r31,r2,-25872 > 80a7be3c04: 39 40 00 00 li r10,0 > 80a7be3c08: f8 01 00 10 std r0,16(r1) > 80a7be3c0c: f8 21 ff 71 stdu r1,-144(r1) > 80a7be3c10: 7d 20 f8 29 lwarx r9,0,r31,1 > 80a7be3c14: 7c 09 50 00 cmpw r9,r10 > 80a7be3c18: 40 82 00 0c bne 80a7be3c24 <.__random+0x34> > > and my small test program (and perf) can use the addresses to correctly > say if LR is relevant or not.
Looks like it's prelink'ed. > > But on RHEL7, objdump shows addresses differently: > > 0000000000063870 <.__random>: > 63870: 7c 08 02 a6 mflr r0 > 63874: fb e1 ff f8 std r31,-8(r1) > 63878: 60 00 00 00 nop > 6387c: 3b e2 9a e0 addi r31,r2,-25888 > 63880: 39 00 00 01 li r8,1 > 63884: 39 40 00 00 li r10,0 > 63888: f8 01 00 10 std r0,16(r1) > 6388c: f8 21 ff 71 stdu r1,-144(r1) > 63890: 7d 20 f8 29 lwarx r9,0,r31,1 > > and perf and my test program fail. Not sure if this is something related > to the way it is built. Then I think struct dso might not be a proper place to cache since a dso can be mapped to different locations/addresses and it has no idea about the location. Maybe it's worth move the caching logic to a different place like struct thread as libunwind does now, and make it generic so that the arch's can also get the benefit when unwinding. A problem I can expect is that it will have thread x dso number of cache entries which can consume a lot of memory and fd IMHO. Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
