Re: [DynInst_API:] commit: further 9.1 fixes

[Bill Williams <bill@xxxxxxxxxxx>]

On 12/08/2015 02:16 PM, Xiaozhu Meng wrote:

On Tue, Dec 8, 2015 at 1:26 PM, Bill Williams <bill@xxxxxxxxxxx> 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