Can you send me the source for the program you're using to do the rewriting?
-- John
On 6/1/2016 12:04 PM, Mohamed Elsabagh wrote:
No. Ubuntu 16.04 x86_64.
On Wed, Jun 1, 2016 at 12:47 PM John Detter <[email protected]
<mailto:[email protected]>> wrote:
Mohamed,
Is this on Windows?
-- John
On 5/31/2016 6:25 PM, Mohamed Elsabagh wrote:
Hi John,
I pulled the latest commits to master. Now I don't get any
errors, but the resulting executable file still doesn't run. It
gives the same error: "cannot execute binary file: Exec format
error." Any suggestions?
Mohamed
On Tue, May 31, 2016 at 6:24 PM John Detter <[email protected]
<mailto:[email protected]>> wrote:
Hey Mohamed,
We found the issue that was causing the assert and we updated
the master branch on github. If you want to clone or pull the
most recent version it should have the fix for your issue.
Let me know if you have any other issues,
-- John
On 5/31/2016 3:57 PM, Mohamed Elsabagh wrote:
Hi Josh,
I just tried again, on a vanilla VM and a fresh clone from
https://github.com/dyninst/dyninst.git, and I am still
getting the same exact message on stderr:
decodeOneOperand() called with unknown addressing method 18
And the resulting binary does not run: Exec format error.
I also tried: `parseThat --binary-edit=ssh.dyn -i 0
/us/bin/ssh`, and the resulting binary (ssh.dyn) also fails
to load, giving the same Exec format error.
When I run `file ssh.dyn`, the output shows no interpreter.
What do you think?
Mohamed
On Tue, May 31, 2016 at 3:26 PM John Detter
<[email protected] <mailto:[email protected]>> wrote:
Mohamed,
I did a fresh clone from github and I was able to
instrument /usr/bin/ssh on Ubuntu 16.04 server addition,
are you sure you are setting your LD_LIBRARY_PATH,
C_INCLUDE_PATH and CPLUS_INCLUDE_PATH to the right
directories? You may be installing the newly built
libraries into a directory that isn't being searched by GCC.
If you are installing globally and you are installing
into `/usr/local` you may have to include these
directories in your environment:
export LD_LIBRARY_PATH="/usr/local/lib"
export C_INCLUDE_PATH="/usr/local/include"
export CPLUS_INCLUDE_PATH="/usr/local/include"
If you are still having issues, could you send me a
tarball of your dyninst directory (source included)?
That way I know we're both looking at the same thing.
-- John
On 5/31/2016 12:52 PM, Mohamed Elsabagh wrote:
Yes, that's what I did. I did a fresh clone and install
from github.com/dyninst/dyninst
<http://github.com/dyninst/dyninst>. But I am now
getting a different error:
decodeOneOperand() called with unknown addressing method 18
And even though the output binary is created, it does
not execute (exec format error).
Again, I am testing with /usr/bin/ssh on Ubuntu 16.04,
without any instrumentation (open, get default module,
get procedures, save).
Thanks,
Mohamed
On Tue, May 31, 2016 at 1:22 PM John Detter
<[email protected] <mailto:[email protected]>> wrote:
Mohamed
git.dyninst.org <http://git.dyninst.org> is now
just a mirror and unfortunately it looks like it
isn't quite up to date.
http://github.com/dyninst/dyninst will get you the
latest commits.
If you want to update your origin:
git remote remove origin
git remote add origin
http://github.com/dyninst/dyninst
git pull origin master
-- John
On 5/31/2016 11:57 AM, Mohamed Elsabagh wrote:
Hi John,
I pulled the latest commit from git.dyninst.org
<http://git.dyninst.org>, which resulted in the
error in my previous email.
Now using a clone from the github path your
provided, I am getting the following message on
stderr:
decodeOneOperand() called with unknown addressing
method 18
And even though the output binary is created, it
does not execute (exec format error).
Again, I am testing with /usr/bin/ssh on Ubuntu
16.04, without any instrumentation (open, get
default module, get procedures, save).
Thanks,
Mohamed
On Tue, May 31, 2016 at 11:37 AM John Detter
<[email protected] <mailto:[email protected]>> wrote:
Mohamed,
Are you sure you are using the latest master?
In my version of
arch-x86.C line 7993 isn't inside the
ia32_decode function. Could you
try pulling from master and
rebuilding/rerunning? If you could provide
another stack trace that would be really helpful.
-- John
P.S. here is the latest commit information for
master
(http://github.com/dyninst/dyninst):
commit df1523dd4003107b959046dd047402642f530c43
Merge: 85cebd3 06c649f
Author: Bill Williams <[email protected]
<mailto:[email protected]>>
Date: Fri May 27 14:37:50 2016 -0500
Merge pull request #61 from
dyninst/Functions_not_filed_into_correct_Modules
Fix Function/Module mapping
On 5/30/2016 9:06 PM, Mohamed Elsabagh wrote:
> There seems to be a different issue now:
calling getProcedures() on
> the default module of a stripped PIE results
in an assertion failure
> at common/src/arc-x86.C:7993. It seems that
the heuristic gap parser
> is trying to decode the assembly as x86_32
instead of x86_64 (I may be
> wrong though). Exact stack trace is attached.
>
> This is triggered by simply opening the
binary, getting the default
> module, then calling getProcedure.
>
> Sample offending program is /usr/bin/ssh on
Ubuntu 16.04 x86_64.
_______________________________________________
Dyninst-api mailing list
[email protected]
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
