aboutsummaryrefslogtreecommitdiff
path: root/src/client/ios/handler
diff options
context:
space:
mode:
authorScott Graham <scottmg@chromium.org>2017-02-23 10:26:46 -0800
committerScott Graham <scottmg@chromium.org>2017-02-23 18:28:02 +0000
commit19af23e3c033fb79e6157d7c113d50b6473e1243 (patch)
tree23fedc3a7467afdec68e1b7c7678686f3a8dba97 /src/client/ios/handler
parentMake stack sanitization elide pointers to non-executable mappings. (diff)
downloadbreakpad-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/client/ios/handler')
0 files changed, 0 insertions, 0 deletions