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
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,Â
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
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. 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 5/31/2016 11:57 AM, Mohamed Elsabagh wrote:
Hi John,Â
I pulled the latest commit from 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
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 <wwilliam47@xxxxxxxxx>
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.
|