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

[Bill Williams <bill@xxxxxxxxxxx>]

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.
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.
> _______________________________________________
> Dyninst-api mailing list
> Dyninst-api@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api

--
--bw

Bill Williams
Paradyn Project
bill@xxxxxxxxxxx