fix insnCodeGen::modifyData's 64-bit conversion #163
Conversation
On RHEL6 with a prelinked `/lib64/libc-2.12.so`, all of tests involving fork instrumentation were getting SIGSEGV in the mutatee. This worked in 9.1, and it also works fine after `prelink -u` to undo libc. Using git-bisect found 2b86eb4 as the point of regression. It seems prelink ends up with libc sitting far away from the relocation buffer, more than a 32-bit displacement, so `insnCodeGen::modifyData` decides to rewrite that to a 64-bit immediate. To do this, it has to emit additional instructions first. But after the commit above, part of the rewritten instruction has already been written when we're trying to emit those extras, and things gets clobbered. This patch emits those preamble instructions first, before any part of the newly rewritten instruction is copied out.
|
This looks good to me, were you getting this crash on 64 bit x86 or 32 bit? |
|
This was crashing on x86_64. Isn't this conversion impossible for 32-bit? |
|
Oh yeah, duh |
|
Ok, is there anything to hold this up? We outsiders can't see what Jenkins is doing on follis... |
|
You should be good! |
|
@cuviper Any experience with the AWS-hosted Jenkins here: https://bitnami.com/stacks/developer-tools? An opaque-to-world Jenkins (that also can't properly respond to github) is not the world's most useful CI tool, and I'd certainly rather get it off of my development box... |
|
@wrwilliams I've done a ton of work with AWS in the past if you need any help, especially if it's setting up a Jenkins box |
|
I don't have any experience setting up Jenkins. Another option is buildbot, e.g. my colleague runs this for GDB: http://gdb-build.sergiodj.net/. I'm not sure where the individual builders are though -- probably still just random development boxes. I think Rust uses buildbot on AWS, with Homu for GitHub integration -- see rust-infra. But again, I haven't run any of these things myself. |
On RHEL6 with a prelinked
/lib64/libc-2.12.so, all of tests involvingfork instrumentation were getting SIGSEGV in the mutatee. This worked
in 9.1, and it also works fine after
prelink -uto undo libc. Usinggit-bisect found 2b86eb4 as the point of regression.
It seems prelink ends up with libc sitting far away from the relocation
buffer, more than a 32-bit displacement, so
insnCodeGen::modifyDatadecides to rewrite that to a 64-bit immediate. To do this, it has to
emit additional instructions first. But after the commit above, part of
the rewritten instruction has already been written when we're trying to
emit those extras, and things gets clobbered.
This patch emits those preamble instructions first, before any part of
the newly rewritten instruction is copied out.