I'm trying to set option -fstack-protector-all in GCC 3.4.3 compiler for enabling some stack smashing protection scenarios. However when compiling with this i got error: unrecognized command line option "-fstack-protector-all"
. So seems this option isn't implemented in GCC 3.4.3 ?? or Am I missing something ?
If it is not implemented in older GCC compiler what is the best / easiest alternative to this ?
Or maybe some useful code pattern to implement stack-smashing protector in C code itself ?
Thanks
You seem to be only one minor version off a gcc version that seems to be able to provide you with this particular smash protection. I found this when googling:
http://www.research.ibm.com/trl/projects/security/ssp/
Maybe you could upgrade to that one (one minor number up) and still be compatible with your vendor?
Additionally, as at least for a number of years canary values are default set in gcc (no need to use the option you mention), have you looked at the disassembly of a simple program? If you see some storing/loading from a (gs) location near end of stack, it's already implemented.
Related
Intel C(++) Compiler has very useful functions to help with profile guided optimisation.
_PGOPTI_Prof_Reset_All();
/* code */
_PGOPTI_Prof_Dump_All();
https://software.intel.com/en-us/node/512800
This is particularly useful for profiling shared libraries which one would use with ctypes in Python.
I've been trying to figure out if either Clang or GCC have similar functionality – apparently not.
Profile guided optimization works differently in gcc and it is enabled with compiler switches. See this question for PGO with gcc.
PGO just recently arrived in clang and is only available starting at version 3.5. The clang user manual gives an overview of how to use it.
It turns out that both have an internal and not properly documented function named __gcov_flush which does this. It is only explained in the source.
/* Called before fork or exec - write out profile information
gathered so far and reset it to zero. This avoids duplication or
loss of the profile information gathered so far. */
It's not quite as convenient as the Intel equivalent though and requires some gymnastics to make it work.
I am developing application using OpenSSL API. As it known, OpenSSL uses miriades of global variables which are taken by Valgrind as errors ("conditional jump or move..." etc). Thus the Valgrind's output gets clogged with errors from shared libraries. This is very inconvenient for debug purposes, because every time I get:
More than X total errors detected. I'm not reporting any more.
Final error counts will be inaccurate. Go fix your program!
The questions are:
Can I disable party libraries (-lssl and -lcrypto in my case) memory checks in Valgrind?
OR can I focus only on "definitly lost" errors?
Thank you.
Adding the option
--undef-value-errors=no
works for me (hide all "Conditional jump or move depends on uninitialised value(s)").
For more information see Valgrind's man page.
Valgrind can be configured to suppress errors in libraries.
Details on this you find here: http://valgrind.org/docs/manual/manual-core.html#manual-core.suppress
From the web-page linked above:
Note: By far the easiest way to add suppressions is to use the --gen-suppressions=yes option described in Core Command-line Options. This generates suppressions automatically. For best results, though, you may want to edit the output of --gen-suppressions=yes by hand, in which case it would be advisable to read through this section.
You need to compile OpenSSL with the PURIFY flag (-DPURIFY in CFLAGS) to get rid of the errors. Do not use the version compiled that way in your final application, only for debugging purpose, because it decreases the entropy used in various places.
For example, compile OpenSSL in debug mode with :
./config -d no-static shared zlib -Wa,--noexecstack -DPURIFY -O0 -ggdb3
Please note that you might also disable warnings generated by your own faulty code if you disable / supress all checks in OpenSSL. For example when you pass not fully initialized structures to OpenSSL functions, this can also result in "conditional jump or move..." errors and you probably want to see those.
In reference to my earlier question here, I found out a possilbe bug in GCC 4.4.3 when it did not support following pragmas in the source code for optimization (although it says 4.4.x onwards it does!)
#pragma GCC optimize ("O3")
__attribute__((optimize("O3")))
Tried both above options but both gave compile time errors in the compiler itself(See the error message snapshot posted in the link mentioned above)
Now are there any further options for me to enable different optimization levels for different functions in my C code?
From the online docs:
Numbers are assumed to be an optimization level. Strings that begin with O are assumed to be an optimization option, while other options are assumed to be used with a -f prefix.
So, if you want the equivalent of the command line -O3 you should probably use the just the number 3 instead of "O3".
I agree that this is a bug and should not generate an ICE, consider reporting it along with a small test case to the GCC guys.
Now are there any further options for me to enable different optimization levels for different functions
in my C code?
Your remaining option is to place the functions in their own .c file and compile that .c file with the optimization flag you want.
I am using GCC crosscompiler to compile to an ARM platform. I have a problem where, using opitmization -O3 gives me a "bad immediate value for offset (4104)" on a temp file ccm4baaa.s. Can't find this file either.
How do I debug this, or find the source of the error? I know that it's located somewhere in hyper.c, but it's impossible to find it because there is no errors showing in hyper.c. Only the cryptic error message above.
Best Regards
Mr Gigu
There have been similar known bugs in previous releases of GCC. It might just be a matter of updating your version of the GCC toolchain. Which one are you using currently?
In order to debug the problem and find the offending source, in these cases it helps to add the gcc option -save-temps to the compilation. The effect is that the compiler keeps the intermediate assembly files (and the pre-processor output) for you to examine.
Just curious. Using gcc/gdb under Ubuntu 9.10.
Reading a C book that also often gives the disassembly of the object file. When reading in January, my disassembly looks a lot like the book's; now, it's quite different - possibly more optimized (I notice some re-arrangements in the assembly code now that, at least in the files I checked, look optimized). I have used optimization options -O1 - -O3 for gcc between the first and second read, but not before the first.
(1) Is the use of optimization options persistent, aka, if you use them once, you'll use them until switching them off? That would be weird (browsed man file and at least did not see anything to that sort). In the unlikely case that it is true, how do you switch them off?
(2) Has gcc's assembly changed through any recent upgrade?
(3) Does gcc sometimes produce (significantly) different assembly code although same compile options are chosen?
Thanks much.
1) No, the options don't persist.
2) Yes, the optimisers are constantly being changed and improved. If your gcc packages have been upgraded, then it is quite likely that the assembly generated for a particular source file will change.
3) Compiling with gcc is a deterministic process; if you compile the same source with the same version of gcc and the same options for the same target, then the assembly produced should be the same (modulo some symbol names).