For a class assignment we needed to write a compiler. This includes an optimizer portion. In other words, we take in a file with some "code". An output file is generated. In the second step we take in the outputted code and remove any "dead" code and re-output to a second file. I have some problems with the optimizer portion and would like to use gdb. But I can't get gdb to operate properly with the input and output files arguments. The way we would normally run the optimizer is:
./optimize <tinyL.out> optimized.out
where tinyL.out is the file outputted in the first step and optimized.out is the file I want to output with the new optimized and compiled code.
I have searched Google for the solution and the tips I have found do not seem to work for my situation. Most people seem to want to only accept an input file and not output a separate file as I need to do.
Any help is appreciated (of course)
I'm not exactly sure what you're asking. But since I'm not yet able to comment everywhere, I write this answer with a guess and edit/delete if necessary.
When GDB is started and before you start the program you wish to debug, set the arguments you want to use with set args.
A reference to the documentation.
You just need to do the file redirection within gdb.
gdb ./optimize
(gdb) run < tinyL.out > optimized.out
https://stackoverflow.com/a/2388594/5657035
Related
I need someone to outline how to pass command line arguments to CLion. What I've found so far hasn't worked for me. Specifically I need to know how to pass multiple arguments to the program from the command line.
If you click on Run-Edit Configurations you can create an "Application" configuration that allows you to provide the Program arguments - either in a single line, or in a separate window one argument per line.
I landed on this SO page as I was using CLion with Rust.
For Rust I was able to add the command line arguments to the end of the Run\Edit Configurations\Command. Notice the required --.
I got this tip from Jetbrains.
For C, it was Run\Edit Configurations\Program Arguments, as #Zulan said.
I always use the -x (or debug flag) when it come to bash script, or shell scripts in general.
Now i'm curious to know, is there an equivalent, either using a specific compiler options, (i use gcc, but i don't mind any other compilers) or by using a specific code in my project?
Basically i just wanted a way to emulate what bash does (using the debug flag) which show which command/function was launched first, in order, and also show the output of said function, with additional errors message etc.But for C.
I'm aware of most debug option out there, especially considering the compiler, but i really wish i could do this in my C projects too.(especially the part where it show what is executed in order, like bash does with -x)
NB: There isn't any goal in this specific question beside the question itself, as i'm just curious if this exist, and thus don't have any need for it beside the actual knowledge acquired from said answered question.
Yes, you can mimic this behaviour with a debugger.
With GDB for instance you can write "Init Files" and "Command Files" in which you can write a simple loop:
break main
run
while 1
next
end
If you put a file named .gdbinit in the directory where you start gdb, this file will be executed or gdb will lead you on the way to configure it in order that it will be executed.
The other option is to pipe this file into your gdb-call:
gdb a.out < debug_me_like-x
Where the "debug_me_like-x" file is the one mentioned above.
As a reference for the "Command Files" have a look here.
I have some C++ code like this that I'm stepping through with GDB:
void foo(int num) { ... }
void main() {
Baz baz;
foo (baz.get());
}
When I'm in main(), I want to step into foo(), but I want to step over baz.get().
The GDB docs say that "the step command only enters a function if there is line number information for the function", so I'd be happy if I could remove the line number information for baz.get() from my executable. But ideally, I'd be able to tell GDB "never step into any function in the Baz class".
Does anyone know how to do this?
Starting with GDB 7.4, skip can be used.
Run info skip, or check out the manual for details: https://sourceware.org/gdb/onlinedocs/gdb/Skipping-Over-Functions-and-Files.html
Instead of choosing to "step", you can use the "until" command to usually behave in the way that you desire:
(gdb) until foo
I don't know of any way to permanently configure gdb to skip certain symbols (aside from eliding their debugging information).
Edit: actually, the GDB documentation states that you can't use until to jump to locations that aren't in the same frame. I don't think this is true, but in the event that it is, you can use advance for the same purpose:
(gdb) advance foo
Page 85 of the GDB manual defines what can be used as "location" arguments for commands that take them. Just putting "foo" will make it look for a function named foo, so as long as it can find it, you should be fine. Alternatively you're stuck typing things like the filename:linenum for foo, in which case you might just be better off setting a breakpoint on foo and using continue to advance to it.
(I think this might be better suited as a comment rather than an answer, but I don't have enough reputation to add a comment yet.)
So I've also been wanting to ignore STL, Boost, et al (collectively '3rd Party') files when debugging for a while. Yesterday I finally decided to look for a solution and it seems the nearest capability is the 'skip' command in GDB.
I found the 'skip' ability in GDB to be helpful, but it's still a nuisance for me because my program uses a lot of STL and other "3rd Party" template code. In this case I have to mark a bunch of files as skip. After the 2nd time doing so I realized it would be more helpful to be able to skip an entire directory--and most helpful to skip a directory and all subdirectories. That way I can skip, for example, /usr since none of my code lives there and I typically have no interest in debugging through 3rd party code. So I extended the 'skip' command in gdb to support a new type 'dir'. I can now do this in gdb:
skip dir /usr
and then I'm never stopped in any of my 3rd party headers.
Here's a webpage w/ this info + the patch if it helps anyone: info & patch to skip directories in GDB
It appears that this isn't possible in GDB. I've filed a bug.
Meanwhile, gdb has the skip function command. Just execute it when you are inside the uninteresting function and it will not bother you again.
skip file is also very useful to get rid of the STL internals.
As Justin has said, it has been added in gdb 7.4. For more details, take a look at the documentation.
Is it possible for a program to open up a text file and use it as c++ code? If so, how? What if a program wanted to append code from a text file to itself? Can that happen?
Thanks!
Depends on what you mean by "text file" and "use it as c++ code." If by "text file" you mean a file containing uncompiled C++ code, and by "use it as C++ code" you mean execute it, the answer is no, you'd need to compile it first before it's of any real use (unless you want to write some sort of interpreter or compiler).
With regards to your second question, I suppose it's possible, but it'd be really hard because you would need to compile the C++ code in that text file into binary, then insert it into the program in a meaningful way.
If you're doing this just for curiosity, you might have better luck with an interpreted language (such as Perl or Ruby). I was a bit curious myself, so I took a stab at the problem with the following ruby script (saved in alpha.rb):
File.open('alpha.rb', 'a') do |file1|
file1.puts "\nprint 'Sneaky Addition!'";
end
After you run it, you'll see that a new line of code has been added. If you run it a second time, it'll run the code. I believe the reason that it isn't run the first time is that the file is already loaded into Ruby when it's run, so it doesn't see the change to the file until it reloads it.
Of course, we could possibly get around this by using a second file (as explained here)...
Alpha.rb
print "Alpha running...\n"
File.open('beta.rb', 'a') do |beta|
beta.puts("\nprint \"But alpha got the last word.\\n\"")
end
load 'beta.rb';
Beta.rb
print "Beta running...\n"
File.open('alpha.rb', 'w') do |alpha|
alpha.puts("print \"Sneaky Beta addition.\\n\"")
alpha.puts("\nprint \"Beta overwrote alpha!\\n\"")
alpha.puts("\nprint \"This code only works once =) \\n\"")
end
load 'alpha.rb'
I suppose you might be able to do something similar in C++, but it'd be much more complicated since you would be compiling your code into binary, and even then you probably can't just append it.
I'm just starting programming and going through K&R to try and learn C. I've gotten to the section on command line arguments (5.10) but now I'm stumped. Every time I try and open a program I've written with command line arguments I'm told that file X, X being the argument, doesn't exist.
`gcc -o find find.c
open find test
The file /Documents/Learning_C/test does not exist.`
Any suggestions? Thanks
What system are you on? In Unix/Linux you compile & run your executable via:
gcc -o find find.c
./find test
As others have noted, when you prefix your binary with "./", there wont be any naming conflicts. However, if you made find accessible in your $PATH, you might have some conflicts with find and test--standard programs with most *nix distributions... Maybe you could choose more specific names (i.e. ./myFind testArg)
Try giving your output executable a different name.
I suspect your executing the system find command which is looking for a directory called 'test'.
Or try forcing it by executing
./find toto
Edit: Prepending the ./ to the command is important because it tells the shell to execute the find in the current directory as opposed to the first 'find' that exists in your PATH. It is normally recommended that you don't have . (the current directory) in your PATH for security reasons.
HTH
P.S. Forgot to say good one for working through K&R. I just finished doing the same after working in C for thirty years and it was good to get back and refresh the mind!
Instead of making us all individually guess what exactly you're doing wrong, perhaps you should paste the program you're using for the illustration mentioned ?