linux-kernel - Re: [PATCH 01/32] perf tools powerpc: Cache the DWARF debug info

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Fri, 31 Oct 2014 12:10:17 +0900
From:	Namhyung Kim <namhyung@...nel.org>
To:	Sukadev Bhattiprolu <sukadev@...ux.vnet.ibm.com>
Cc:	Arnaldo Carvalho de Melo <acme@...nel.org>,
	Ingo Molnar <mingo@...nel.org>, linux-kernel@...r.kernel.org,
	Anton Blanchard <anton@....ibm.com>,
	Jiri Olsa <jolsa@...hat.com>,
	Arnaldo Carvalho de Melo <acme@...hat.com>
Subject: Re: [PATCH 01/32] perf tools powerpc: Cache the DWARF debug info

Hi Sukadev,

On Wed, 29 Oct 2014 14:26:20 -0700, Sukadev Bhattiprolu wrote:
> Namhyung Kim [namhyung@...nel.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 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/