diff options
author | Scott Graham <scottmg@chromium.org> | 2017-02-23 10:26:46 -0800 |
---|---|---|
committer | Scott Graham <scottmg@chromium.org> | 2017-02-23 18:28:02 +0000 |
commit | 19af23e3c033fb79e6157d7c113d50b6473e1243 (patch) | |
tree | 23fedc3a7467afdec68e1b7c7678686f3a8dba97 /src/common/dwarf/dwarf2diehandler.cc | |
parent | Make stack sanitization elide pointers to non-executable mappings. (diff) | |
download | breakpad-19af23e3c033fb79e6157d7c113d50b6473e1243.tar.xz |
Handle ntdll only emitting PUBLIC at func entry
This handles a case encountered in ntdll.dll symbols for Windows 7,
where a PUBLIC would be emitted only for the entry point to the
function. The body of the function, however, is split in a PGO-ish
fashion to another remote location in the binary. Because of this, there
were large gaps in the RVA space that would be attributed to the "last"
function that happened to have an entry point before the gap. In
practice, something like this:
0x100 Func1
0x110 Func2
0x120 Func3
0x130 Func4
...
0x800 LaterFuncs
The bodies of Func1/2/3 tend to be implemented as a fast-path check,
followed by a jmp to somewhere in the range between 0x130 and 0x800.
Because no symbols are emitted for this range, everything is attributed
to Func4, causing crash misattribution.
In this CL, the change is: after emitting the entry point symbol, also
walk in the original OMAP entries through the untranslated binary, and
for each block until we resolve to a new symbol (via the same mechanism
as we found the entry point) emit another PUBLIC indicating that there's
another block that belongs to that symbol. This effectively breaks up
the "0x130 - 0x800" range above.
R=mark@chromium.org
BUG=chromium:678874
Change-Id: Ib3741abab2e7158c81e3e34bca4340ce4d3153a1
Reviewed-on: https://chromium-review.googlesource.com/446717
Reviewed-by: Mark Mentovai <mark@chromium.org>
Diffstat (limited to 'src/common/dwarf/dwarf2diehandler.cc')
0 files changed, 0 insertions, 0 deletions