-
Notifications
You must be signed in to change notification settings - Fork 3
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
Crash on first line of code #17
Comments
I strongly recommend to test programs compiled with Stabilizer runtime writes If stabilizer works correctly you should see the original addresses of a function only before the signal raised ( |
Hmm, valid point. That said, |
I use coredumps and printfs. They are slower, but at work I rarely had a luxury of interactive debugging. With stabilizer I find it very useful to log relocation addresses, so that I can match raw asm to symbols. I'll take a look at |
I don't see any crashes with
|
That is quite strange. Regarding debugging; Printf I am used to of course, but I have never tried to do any segfault debugging with that, should work but it does sound a bit cumbersome. |
If you use containers, I have a couple for testing stabilizer. This one is for stabilizer and has customizable llvm version (unfortunately llvm provides packages for debian:unstable starting from version 13):
This one for zlib-ng:
|
Tested using:
Clang 12.0.1 (Fedora 12.0.1-1.fc34)
Built zlib-ng from
develop
branch and ran the resulting example (basic self-tests) binary.This is the first line of actual code in main(), after variable definitions.
Did a little experiment to see whether adding a line above that with
__asm__("nop");
would do anything at all.Not much changed, but the call address seems to be very random, unless there is a bit pattern I am not seeing.
Seems to me like something is still quite wrong somewhere in the Stabilizer plugin pass when it comes to patching the call addresses.
The text was updated successfully, but these errors were encountered: