I was doing a homework assignment and I wanted to use the <ncurses.h>. So the gcc filename.c -lncurses generates an assembler output and./a.out executes the code. In order to avoid ***stack smashing detected*** or segmentation fault error I also need to execute the gcc filename.c -fno-stack-protector. Is there any way through which I could execute both the commands on the terminal or the code could execute the -fno-stack-protector command?
ps : please go easy I am a complete noob :) :P
GCC can take multiple options on the command line. You should be able to pass any combination of -f and -l options, provided those options are compatible. You can get a great deal of information about the correct syntax for invoking GCC by running man gcc (or, on some systems, info gcc).
And, as I commented above, if you're getting a "stack smashing detected" error, the solution is not to pass -fno-stack-protector (which just disables the code GCC uses to detect these kind of bugs), but rather to fix the actual bug in your program that is causing the stack to get overwritten.
Related
Following this process
from an earlier question (see answer).
gdb is a huge improvement over spim, but I'd like to use the compile code feature of gdb, to inject arbitrary mips instructions at the point of execution.
I have read Compiling and injecting code in gdb. When I run run compile code <anything>, I get the error "compilation failed, unrecognized argument -m32". Then when I run set debug compile in gdb, and I try compile code <anything> again, I see that the argument -m32 is passed to mips-linux-gnu-gcc.
I tried overriding the compilation arguments using set compile-args -march=mips32r3, which adds the compilation argument, but -m32 is still passed and still gives me an error.
How do I prevent -m32 from being passed? Is there a clean workaround (short of making a dummy script that strips -m32 before compiling?)
How do I prevent -m32 from being passed?
It looks like this is the case where GDB developers thought that "GDB knows better", and didn't provide any way to override this.
Specifically, the -m32 comes from default_gcc_target_options(), which unconditionally adds -m%d with gdb_arch_ptr_bit() as the argument.
Short of building your own GDB or providing a GCC wrapper that strips -m32, I don't see any way to get rid of this argument.
Make this script, special-gcc. Make it executable, chmod 777 special-gcc. The script uses exec to have the process replaced with the gcc invocation, as opposed to spawning a child process. Arguments are $#, stored in array, filtered in loop, then passed to the gcc invocation.
#!/bin/bash
declare -a args=()
#!/bin/bash
echo -- "----------------" >> ~/gcc-wrapper-log
for arg in "$#"
do
if ! [[ "$arg" == '-m32' ]]; then
echo -- "$arg" >> ~/gcc-wrapper-log
args+=("$arg")
fi
done
exec mips-linux-gnu-gcc -static "${args[#]}"
Inside gdb, run the command set compile-gcc /path/to/special-gcc. Attempt some command compile code <anything>. Then in gcc-wrapper-log you can see all the arguments to the compilation, can selectively disable them in the script.
For me, the compilation succeeded, but because I am using the mips-linux-gnu-gcc cross compiler binary, gdb seems not to link the resulting .o file correctly. See the docs for details on the internals of the compile code feature. Somewhere in the steps "Relocating the object file" is where the process failed for me for mips-linux-gnu-gcc.
However, this is still a clean and easy way to precisely control the compilation arguments used by gdb compile code.
I'm doing an assignment that is working with shared memory, and i'm getting segfaults whenever I run the code. So i tried using the GDB debugger to see where the fault is occurring,but when it runs the code, it exits normally and says its fine. i pasted what wasin the terminal below
./main
This is the cb 16669520, This is the dbInfo 2117869600, and this is the db 2117869608
this is the number of processes 1
Segmentation fault (core dumped)
the first two lines it prints out are fine, but the code never reaches the end of the main. THen when I run the debugger...
gdb ./main
(gdb) run
Starting program: /*path*/
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
This is the cb -8848, This is the dbInfo -243544032, and this is the db -243544024
this is the number of processes 2
The code got this far[Inferior 1 (process 15840) exited normally]
(gdb) backtrace
No stack.
Run your program with valgrind. It will detect invalid reads and writes to memory, tell you where they happen and, most likely, be helpful enough to tell you exactly what line caused them. One of these errors is what's causing your program to segfault.
Don't forget to add the -ggdb3 flag when compiling your program :)
If valgrind does not help (usually it wlll), consider enabling warning at compile time. If possible, the compile should be 'clean', without any warning. GCC can detect many common errors.
gcc -Wall ... file.c
# or even
gcc -Wall -Wextra ... file.c
from gcc man:
-Wall
This enables all the warnings about constructions that some users
consider questionable, and that are easy to avoid (or modify to
prevent the warning), even in conjunction with macros. This also
enables some language-specific warnings described in C++ Dialect
Options and Objective-C and Objective-C++ Dialect Options.
-Wextra
This enables some extra warning flags that are not enabled by
-Wall. (This option used to be called -W. The older name is still
supported, but the newer name is more descriptive.)
I am using Linux now, and trying to compile this by gcc BUT.......
this is my truly simple code:
#include <stdio.h>
int main(){
printf("Hello world\n");
return 0;
}
and this is so much weird output:
./try.c: line 3: syntax error near unexpected token `('
./try.c: line 3: `int main(){'
why is it?
I have tried the right way to compile it, such:
gcc file_name.c -o file_name and other types of way of compiling
chmod +rwx file_name.c
./file_name.c
but still I got that result, why?
You have to compile the code first.
Follow these steps.
gcc try.c -o try.out
to compile the code. The -o option is given to give a custom name to the executable that will be produced.
Then, you can run it by typing
./try.out
To run the executable.
Be informed though, that there are a number of command line options that you can use to get the information about your code and add more functionality. See this page for more information.
You are trying to execute the .c file, remove the trailing .c from the name of the file you want to execute.
Like this:
gcc -Wall -Wextra -pedantic -Werror -o executable file_name.c
You should not need to make it executable, it should already be executable since the compiler will do that.
./executable
As you see, I've passed some parameters to gcc to let it help in diagnosing problems, sometimes these problems are caused by your lack of knowledge and some other times because you write code quickly and miss some details. So using them is good (although compilation is slower, but that doesn't matter if you have a good and fast machine, wehreas having issues in the code does matter).
The meaning of these flags are as follows
-Wall Enable all warnings. Really some are not enabled, but most are.
-Wextra Enable extra warnings.
-pedantic make the compiler pedantic, i.e. stick strictly to the desired (default for this version of gcc) standard.
-Werror Consider that warnings are errors.
Also, you could have guessed this if you see what the error says
./try.c: line 3: syntax error near unexpected token `('
./try.c: line 3: `int main(){'
as you can see the shell is trying to execute the source code as if it was a shell script, so you can immediately notice that this is not the executable file generated by gcc, and then you would notice the .c in the file name.
Try
gcc try.c
./a.out
Compiles the code and runs it. Please read the manual page for gcc and there are many delights to behold (extra checking etc)
I'm running into a little problem and require some assistance. I would like to run gprof on some OpenMP and MPI hybrid code as a part of my testing. I understand that Gprof relies on a binary file which is created when you compile GCC (or mpicc) with a -pg switch.
I have tried adding this switch and my compiling succeeds (as in no errors are reported), however, the binary file is not created, but the executable is created as normal. I have also tried doing this on much simpler code, which uses pthreads, with the same result.
Please examine the below and let me hear your thoughts.
gcc -pg --std=gnu99 -pthread -Wall -o pthreadsv0 pthreads.c
GCC compiling with -pg doesn't produce binary needed for Gprof.
I suspect that the binary file you mention is in fact the profile data file (gmon.out), and it is generated when you run your program (which has to be compiled with the -pg flag).
Just execute your program and see if a gmon.out file is there.
The Gprof information is created when you execute the program after you compile with the -pg option. Try running your program. (You're profiling (Gprof) the execution of the program.)
The -pg compile option adds the necessary logic to create the profiling information when the program is executed. Executing the program, several times if desired or needed, allows the 'instrumented' code to write the data describing the logic flow and timing to the gmon.out file.
I encountered the same problem. The problem arose because I was shutting the program's execution with Ctrl + C instead of a proper exit (closing the GUI window in my case).
To create the .out executable, I have to enter:
$: make
$: myprogram.out name.ged
My program incorporates a command line argument, thus the "name.ged".
Whenever I run gdb after getting a segmentation fault (core dumped), I enter:
$: gdb a.out core
(gdb): bt
I then use the back trace command, and gdb returns:
#0 0x4a145155 in ?? ()
#1 0x08a16ce0 in ?? ()
I even tried using the up command t move up the stack, but still no luck. I can't tell which line in my program is giving me the seg fault. gdb works with my other programs that do not involve a Makefile and command arguments, so I'm wondering if my commands are incorrect.
Summarizing the comments (before anyone else does :).
Your executable file is missing the symbolic information that gdb needs to display the relevant source code. You need to add the -g option to the compile command and produce a new executable. Then re-run your failing test to produce a new core file. gdb with this executable and core will be able to show you the stack of function calls using backtrace.
In a makefile, the easiest way to do this is to add (to) the CFLAGS variable which is used with the implicit .o.c rule.
CFLAGS= -g -Wall -Wextra
You can also add this directly to the command-line (assuming a decent shell :). This sets the value as an environment variable during the execution of the make command (and sub-commands).
$ CFLAGS='-g -Wall -Wextra' make
I'd actually recommend you add this to your bash .profile, so you always get the most information from the compiler.
CFLAGS='-Wall -Wextra'
Then, when you need it, put this in the makefile to make a debuggable executable:
CFLAGS+= -g