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]> 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]> 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. 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]> wrote: >> >>> Mohamed >>> >>> 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, 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]> 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]> >>>> 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
