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] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 29 Oct 2014 14:26:20 -0700
From:	Sukadev Bhattiprolu <sukadev@...ux.vnet.ibm.com>
To:	Namhyung Kim <namhyung@...nel.org>
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

Namhyung Kim [namhyung@...nel.org] wrote:
| > +		if (dwfl_report_offline(dwfl, "", dso->long_name, -1) == NULL) {
| > +			pr_debug("dwfl_report_offline() failed %s\n",
| > +						dwarf_errmsg(-1));
| > +			/*
| > +			 * We normally cache the DWARF debug info and never
| > +			 * call dwfl_end(). But to prevent fd leak, free in
| > +			 * case of error.
| > +			 */
| 
| Well, it can be freed when dso__delete() called at least. :)

Agree. Jiri Olsa also pointed that out. Plan to add that as a part
of couple of other changes Jiri proposed.

| 
| 
| > +			dwfl_end(dwfl);
| > +			goto out;
| > +		}
| > +		dso->dwfl = dwfl;
| >  	}
| >  
| >  	mod = dwfl_addrmodule(dwfl, pc);
| 
| 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.

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.

Sukadev

--
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/