linux-kernel - Re: Fwd: [PATCH-V2] perf symbols: fix symbol offset breakage with separated 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:	Mon, 25 Jun 2012 16:49:51 -0700 (PDT)
From:	Roland McGrath <roland@...k.frob.com>
To:	Dave Martin <dave.martin@...aro.org>
Cc:	Arnaldo Carvalho de Melo <acme@...radead.org>,
	Prashanth Nageshappa <prashanth@...ux.vnet.ibm.com>,
	peterz@...radead.org, akpm@...ux-foundation.org,
	torvalds@...ux-foundation.org, ananth@...ibm.com,
	jkenisto@...ux.vnet.ibm.com, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org, oleg@...hat.com, andi@...stfloor.org,
	hch@...radead.org, rostedt@...dmis.org,
	masami.hiramatsu.pt@...achi.com, tglx@...utronix.de,
	anton@...hat.com, srikar@...ux.vnet.ibm.com,
	linux-perf-users@...r.kernel.org, mingo@...e.hu
Subject: Re: Fwd: [PATCH-V2] perf symbols: fix symbol offset breakage with
 separated debug info

> For one thing, I assumed that the section headers for a debug-only image
> may be bogus garbage and not useful for some aspects of symbol
> processing.  I'm no longer sure that this is the case: if not, then we
> don't need to bother with saving the section headers because once we
> have chosen a reference image for the symbols, we know that image is
> good enough for all the symbol processing.  My previous assumption
> that we may need to juggle parts of two ELF images in order to do the
> symbol processing does complicate things -- hopefully we don't need it.

The section headers in a .debug file are never "bogus garbage".  Aside
from sh_offset fields, they match the original unstripped file except
that sh_type is changed to SHT_NOBITS for each section that is kept only
in the stripped file.

The one issue you have to deal with (in ET_DYN files) is that the
addresses used in the section headers and everywhere else in the .debug
file (symbol table st_value fields, all DWARF data containing addresses,
etc.) may no longer match the addresses used in the stripped file, if
prelink has changed that file after stripping.  For this, all you need
to do is calculate the offset between .debug file and stripped-file
addresses.  The way to do that is to examine the PT_LOAD program headers
(just the first one is all you really need), and take the difference
between the p_vaddr fields of the same PT_LOAD command in the two files.

Thanks,
Roland
--
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/