Re: [DynInst_API:] image::findMain fails for -pie

[Bill Williams <bill@xxxxxxxxxxx>]

On 11/21/2014 01:02 PM, Adrian M Negreanu wrote:
> On Fri, Nov 21, 2014 at 7:51 PM, Bill Williams <bill@xxxxxxxxxxx
> <mailto:bill@xxxxxxxxxxx>> wrote:
>
>     On 11/21/2014 11:36 AM, Josh Stone wrote:
>
>         On 11/21/2014 01:02 AM, Adrian M Negreanu wrote:
>
>             I tried to instrument a strip-ed chrome, as a workaround the
>             processCreate issue(s) , only to find another problem, this
>             time in
>             image::findMain()
>
>
>         As a workaround, since you're the one stripping it, you can try
>         stripping slightly less.  Just removing debuginfo with "strip
>         -g" might
>         be enough to improve your processCreate issues, or use "strip -K
>         main"
>         to at least keep main in the symbol table, making findMain
>         unnecessary.
>
>             findMain() assumes the entry point address to be an
>             immediate operand:
>                mov    $0x40051b,%rdi
>                callq  0x7ffff7fef3f0
>
>             For chrome, I found this instead
>                lea -0x34f7(%rip),%rdi
>                callq 26f20 <__libc_start_main@plt>
>
>             Josh found the same issue with a strip-ed stap, or as he put it
>                "/usr/bin/stap is PIE, and I removed the debuginfo package"
>
>             Any suggestions for this one ?
>
>
>         I think ideally this should find the call in question, then use the
>         dataflowAPI to slice back and find the value of %rdi at this
>         point.  I
>         hope that's smart enough to evaluate things like -0x34f7(%rip),
>         but I
>         haven't played with it much.  PPC does something similar for r8.
>
>         On 32-bit x86, we'll want the last value on the stack instead.
>
>
>     The findMain logic here is sound, but I want to point out that
>     stripping chrome is not actually going to help.
>
>
> So it's sound to expect an immediate value for -pie binaries ? This
> eventually returns NULL, and
> in that case the boostrap fails.
> The strip-ing indeed, it doesn't fix the "processCreate taking too
> long", it only makes a bit bearable.
Sorry, I meant Josh's outlined logic; we should slice back but presently 
don't.
>     Assuming that you don't need the preFork callback, chopping out the
>     preFork instrumentation should be easy enough; I can send out a
>     patch (probably late this afternoon or Monday) that implements the
>     change I discussed in my most recent email if you want a slightly
>     more polished version that doesn't break preFork wholesale.
>
>
> Cool. I'll wait for the patch then.

--
--bw

Bill Williams
Paradyn Project
bill@xxxxxxxxxxx