-
Notifications
You must be signed in to change notification settings - Fork 70
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fcd segfaults on 1993-ant #46
Comments
I'm seeing the same behavior. However, AFAIK, I haven't been able to decompile 1993-ant since the stack frame recovery pass was introduced, so it's nothing new. I looked at it recently while fixing other stack frame recovery bugs, and for a reason that I have yet to figure out, fcd tries to put a The high-level plan was to replace that pass with the type reconstruction pass, but that hasn't come to be yet, and I think that I'll let the idea simmer some more while I find a good resource on constraint solving algorithms. That thing turns out to be pretty hard. Are you seeing a similar failure on another executable, or is it "just" a warning that 1993-ant doesn't work? |
Thanks for the response and insights! I'm not seeing a similar failure on anything else, just thought I'd report/check in case it was something in how I built FCD or otherwise unknown :). I'm good with either leaving this open or marking it closed, whichever you'd prefer. |
If it's just 1993-ant, it's already on my radar, if not terribly high on my list of priorities, so I'll close it. The SUMMARY.md file (in the osx branch; Linux is broken because of Travis restrictions) on the test repository lists the decompilation status of all tracked executables. There are currently 3 known failures: 1993-ant, 1995-esde and 1996-eldby, all because of stack frame recovery. The first tested revision instead had 1993-ant, 1993-leo and 1995-dodsond1 failing. I fixed the latter two, and moving to LLVM 4 broke esde and eldby instead, and I haven't looked into it. |
Interesting, wonder what's causing the OSX failures. 1993-ant is the only failure I'm seeing (Linux, NixOS), FWIW: http://ix.io/pqS |
FWIW the |
Thanks for letting me know. Fcd did 3.9 to 4.0, it seems that we should have had the intermediate state where things were compatible. I'll give it a serious look at some point.
… Le 8 mai 2017 à 11:18, Will Dietz ***@***.***> a écrit :
FWIW the getIndexedType method changed behavior between 3.8 and 4.0, see discussion here <SVF-tools/SVF#18> for some more information and a possible fix via the BridgedGEPIterator.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub <#46 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACtJ5HS29i5odeooTd8m1oq_R2sKUixmks5r31xigaJpZM4MtOjI>.
|
This has been happening for a while now, I think since move to LLVM 4.
The other tests pass, but fcd crashes while trying to process 1993-ant from the fcd-tests repository:
I poked at it a bit and this appears to be due to some changes/bug in
getIndexedType()
when indexing through a struct but I'm not sure how to best resolve it. Anyway, can you take a look?(Also--are you seeing the same behavior?)
Thanks!
The text was updated successfully, but these errors were encountered: