Re: [DynInst_API:] commit: further 9.1 fixes

[Bill Williams]

On 12/09/2015 08:58 PM, Josh Stone wrote:

On 12/08/2015 09:14 AM, Bill Williams wrote:

in the absence of any further showstoppers, this will become 9.1.0.

I'm still hoping dynamic library callbacks will change from modules to
objects, now that there can be many modules per dynamic library.  I
mentioned this again when the change finally landed, but I think that
may have gotten lost under my ABI objections.

It did; it should be easy to fix (technically an API change, though).

Related, I'm now finding that BPatch_object::findFunction behaves poorly
regarding notify_on_failure.  Since it just passes this flag through to
each BPatch_module::findFunction, then I get notified on each module
that didn't have it, even when one ultimately does.  This previously was
never a problem because I only use it on shared objects which were just
one module too.  I'm guessing that old executable objects would have
already had this issue though.  To fix this, maybe BPatch_object should
mask this flag when calling into modules, then print its own
notification if nothing is found in aggregate.  What do you think?

Good catch and that one is I believe simple.

I'll give both of these a whirl to see if they're as easy as they look 
and let you know.


Thanks,
Josh


___
Dyninst-api mailing list
Dyninst-api@cs.wisc.edu
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api

Re: [DynInst_API:] commit: further 9.1 fixes

[Josh Stone]

On 12/08/2015 09:14 AM, Bill Williams wrote:
> in the absence of any further showstoppers, this will become 9.1.0.

I'm still hoping dynamic library callbacks will change from modules to
objects, now that there can be many modules per dynamic library.  I
mentioned this again when the change finally landed, but I think that
may have gotten lost under my ABI objections.

Related, I'm now finding that BPatch_object::findFunction behaves poorly
regarding notify_on_failure.  Since it just passes this flag through to
each BPatch_module::findFunction, then I get notified on each module
that didn't have it, even when one ultimately does.  This previously was
never a problem because I only use it on shared objects which were just
one module too.  I'm guessing that old executable objects would have
already had this issue though.  To fix this, maybe BPatch_object should
mask this flag when calling into modules, then print its own
notification if nothing is found in aggregate.  What do you think?


Thanks,
Josh
___
Dyninst-api mailing list
Dyninst-api@cs.wisc.edu
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api

[DynInst_API:] commit: further 9.1 fixes

[Bill Williams]

Fixes for the following:

* Instruction decoding bugs revealed by the test suite
* dwarf_attr memory leak
* improper handling of malformed DWARF: high_pc can return an error even 
when it's supposedly present, and the associated Dwarf_Error needs to be 
freed
* Windows-specific misuse of temporary strings, resulting in memory 
corruption in our calling convention analysis

* Slicing no longer attempts to follow catch edges
* Exception block parsing properly handles the aligned tag
* Exception block parsing properly recognizes that zero offsets 
correspond to "no catch block" regardless of the presence/absence of a base
* Exception block parsing correctly handles bases other than function 
entry, if present
* Exception block parsing now ignores indirect catch blocks; these 
contain pointers to catch blocks and should be assumed not to be 
statically resolvable.

* Exception table size decoding now matches glibc internals.

All of these are on the 9.1.x branch; in the absence of any further 
showstoppers, this will become 9.1.0. If there is demand for a 9.0.4 
incorporating the various bug fixes and leaving out the ABI breakers, 
let me know and I can package it; if not, folks can just use 9.1.


--bw
___
Dyninst-api mailing list
Dyninst-api@cs.wisc.edu
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api

Re: [DynInst_API:] commit: further 9.1 fixes

[Barton Miller]

How often are these indirect vs. direct?  Does it ever happen that the 
indirect points to static tables of addresses, so is statically resolvable?


--bart


On 12/8/2015 11:14 AM, Bill Williams wrote:
* Exception block parsing now ignores indirect catch blocks; these 
contain pointers to catch blocks and should be assumed not to be 
statically resolvable.

___
Dyninst-api mailing list
Dyninst-api@cs.wisc.edu
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api

Re: [DynInst_API:] commit: further 9.1 fixes

[Bill Williams]

On 12/08/2015 02:16 PM, Xiaozhu Meng wrote:
On Tue, Dec 8, 2015 at 1:26 PM, Bill Williams > 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

Re: [DynInst_API:] commit: further 9.1 fixes

[Xiaozhu Meng]

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

Thanks,

--Xiaozhu
___
Dyninst-api mailing list
Dyninst-api@cs.wisc.edu
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api