On 12/08/2015 02:16 PM, Xiaozhu Meng wrote:
On Tue, Dec 8, 2015 at 1:26 PM, Bill Williams <b...@cs.wisc.edu
<mailto:b...@cs.wisc.edu>> wrote:
On 12/08/2015 12:47 PM, Barton Miller wrote:
How often are these indirect vs. direct? Does it ever happen
that the indirect points to static tables of addresses, so is
statically resolvable?
Mostly they're direct; indirect ones exist in a few places in
newer glibc (and/or libstdc++) versions from what we've seen, but
not at all on a test run on RHEL6.
It's possible that the indirect ones would point to static tables
of addresses, but highly unlikely--there's no reason to encode as
indirect unless you're actually changing the potential catch block
at runtime. Haven't got data about the existence of static tables,
but previously we were recording "catch blocks" that were the
addresses of the pointers, which is IMO actively harmful.
Furthermore, we know that in the cases where there aren't static
tables, we're often getting pointers in .bss, which we obviously
can't even try to follow statically (this was producing crashes).
A measurement on libstdc++ from RHEL7 actually shows results contrary
to our expectations. In this libstdc++, all catch blocks are direct.
We only encounter indirect encoding when we read and skip personality
data. And all indirect pointers go to the .data section.
Based on these results, no wonder previously we are fine with
completely ignoring these indirect pointers as we do not try to
interpret personality data.
So this doesn't affect catch blocks at all, but only how we would find a
personality function (if we cared about such things)--which makes much
more sense, as it would not be trivial to have an indirect catch block
actually work meaningfully. (PC relative and function relative
addressing handle all ASLR/relocation stuff transparently.)
I think this means we can, for the moment, happily ignore indirect
values in EH_FRAME.
Thanks,
--Xiaozhu
_______________________________________________
Dyninst-api mailing list
Dyninst-api@cs.wisc.edu
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api