-
Notifications
You must be signed in to change notification settings - Fork 4
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
Makefile: Add stuff to ease debugging #15
base: master
Are you sure you want to change the base?
Conversation
Add debug variable (with a settable default): make DEBUG=1 # for compiling with debug flags make DEBUG=0 # for compiling with "normal" flags The debug flags include ASAN definitions for finding runtime memory related problems. Add targets for invoking gdb and the test suite: make gdb # enter GDB with appropriate ASAN environment variables make test # run the test suite
I'm torn on seeing such stuff. OTOH, this provides useful features, and good way to bootstrap learning of all that ASAN stuff. OTOH, it's complete kludge for somebody who don't need it and just needs clean makelfile. I'm certainly would be OK with this being Makefile.asan. |
It could be indeed a good idea to provide it as Makefile.asan. I can send another pull request if desired. However, I cannot imagine why someone who develops a program (and re1.5 is a program for development, not for the purpose of actually use as a command) would like to avoid compiling with ASan/UBan (for development purpose), now that it is commonly available in gcc and clang. For example, I tried to run the MicroPython tests, after compiling it (in the unix directory) with ASan/UBan, and it indicated many apparent problems: A problem like A problem like: A problem like: There is also one buffer overflow report (gc.c:284), but it may be bogus. I can open an issue on micropython with the summary of these errors, and the Makefile modifications in order to produce them. |
Well, any software is first of all intended for usage, not development ;-). And re1.5 is library, so it's "usage" is integration into other software. The latest "fashion" in that direction is not even using lib*, bu dropping code into your codebase (I don't like that, but then for uPy, we have a good case why it's useful). Entailing from that, there should be very clean and concise instructions how to integrate re1.5 into your codebase, and clean, concise Makefile is such instructions in "executable form". Seeing "llvm-symbolizer" (far less "/usr/bin/llvm-symbolizer", like you propose), about which nobody knows, doesn't help the cause.
Cool, we now just need to wait some 20 years till asan/uban will be the same this as "ls" or "ld", and such questions won't even make sense. Until then - they're nothing but novelty-du-jour, about which "nobody" knows and which will die (will be killed by their own creators) before they have chance to become popular.
"Apparent" is a keyword here. If such a tool (and there're lot of them!) finds a problem, please verify whether it's true problem or false positive, and submit patch if the former. Keep tally of issues vs false positives, if issues are frequent, and false positives are rare, maybe it's indeed worth enabling it by default for everyone, instead of having someone run occasionally and do end-to-end analysis of each case.
Any contribution is appreciated, but per above, the most useful approach is that someone does end-to-end work on this stuff. Otherwise, such reports may just stay long in queue unattended.
Per above, that would be preferred solution, at least for the time being. |
Usually it is already set up in the environment of the developer. However, I could not assume that , so in order I added it to the Makefile. It is far from ideal, of course, and it is indeed not appropriate for a main Makefile.
Just please note that this is not "a tool" among "a lot of them" other tools. It is an official integral feature of the GCC and CLANG compilers for some time now (2+ years). However, UBsan and Lsan are newer in GCC. When GCC issues a warning on an undefined behavior, unless it is in dead code (a thing that may be rare enough now, I didn't encounter such a thing recently), it is not a good idea to let it remain in the code, because compiler optimizations assume you don't do undefined things, and optimize code according to this assumption (and e.g. remove code you didn't think it would remove). Interesting reading: ASan (address sanitizer) is a great feature of GCC that usually don't have false positives on -O2 code (on -O3 I encountered false positives). For example, it doesn't let you referring an array out of bounds, using indexing or even pointers. This way you can easily find bugs without tedious debugging sessions. In the uPy tests, ASan found a repeated out-of-bound access in one particular place (gc). If uPy unwind the stack itself (not using longjmp), then this may be a false positive. Otherwise, most probably it indicates a problem. I'm not sure I will be able to enter deeply into that. To sum up:
In any case, my propose Makefile has a test target that runs run-tests. Maybe it can be a good idea to add it to the project's Makefile (I can send a pull request). |
Is there anything to do more regarding that? |
Can we please choose option 2 above? Thanks.
Yes, that's good idea, I'm missing that too. |
ping |
Other possible improvements to the Makefile (implemented in my devel branch).
|
ok
Fairly speaking, I don't know why it's not just -g, and using that would be my preference (any other option may not work with a particular toolchain).
I.e. you want add line like the above to Makefile? Sounds good. Thanks! |
Per the discussion in pfalcon#15.
Per the discussion in pfalcon#15.
This is my proposal for a new Makefile.
The added ASAN definitions are for finding memory related bugs (e.g. out of bounds, use after free(), memory leaks, etc.) and various undefined behavior. See the commit message for more info on what has been added.
For -fsanitize=undefined, a recent enough gcc is needed (found on all recent Linux distributions).