On Fri, Nov 21, 2014 at 7:36 PM, Josh Stone <jist...@redhat.com> 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. > That's what I did. While the binary I used is chrome, the problem is not really tied to it, but it applies to -pie binaries in general. > > > 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. > I'll take a look at PPC then, thanks.
_______________________________________________ Dyninst-api mailing list Dyninst-api@cs.wisc.edu https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
