No. Ubuntu 16.04 x86_64. On Wed, Jun 1, 2016 at 12:47 PM John Detter <[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]> 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
