i'm using cs50 appliance.
i've tried to write a new file test.c , found as long as i include int i line, it doesn't generate a new file test, if i remove that line and make again, it can generate test file. then i made changes on the test file, it still output the original file result, no reflect the new changes.
#include <stdio.h>
#include <cs50.h>
int
main (void)
{
printf("Number: \n");
int i = GetInt();
}
it was running properly before though... anyone can help please?
Apparently your default rules for make run the compiler on test.c.
The compiler notices that you are assigning a value to variable i, but you never use that value in any way; it would normally report this as a warning.
Apparently either your compiler or make are configured in such a way that this warning becomes a fatal error to make.
The remedy is to use the variable. It looks as though you need to pick up a book on the C programming language, or follow a course, if that's not what you're doing already.
Related
I know that when I have only one source file in C++, preprocessor commands are done in order they were written, but what if I have more than one source file? How is the decision made, which source file should be taken at first? I've written in both source files such code:
#ifndef b
#define b 10
int a = 15;
#endif
and when I compile, there is an error, that variable a has been already defined. But why, if there is a command #ifndef and #endif?
The order that the compiler processes source files is undefined by the language.
I am assuming you get this error in the linker stage. This is because both your source files define a symbol with the same name, and the linker gives up when trying to merge the object code from each file. If your intent is to let at least one of the files have its own separate version of a, declare it in that file as static. Then the linker error should go away as the static a is limited to its own file.
Edit (updated question)
I have a simple C program:
// it is not important to know what the code does you may skip the code
main.c
#include <bsp.h>
unsigned int AppCtr;
unsigned char AppFlag;
int SOME_LARGE_VARIABLE;
static void AppTest (void);
void main (void)
{
AppCtr = 0;
AppFlag = 0;
AppTest();
}
static void Foo(void){
SOME_LARGE_VARIABLE=15;
}
static void AppTest (void)
{
unsigned int i;
i = 0;
while (i < 200000) {
i++;
}
BSP_Test();
SOME_LARGE_VARIABLE=3;
Foo();
}
bsp.c
extern int SOME_LARGE_VARIABLE;
extern unsigned char AppFlag;
unsigned int long My_GREAT_COUNTER;
void BSP_Test (void) {
SOME_LARGE_VARIABLE = 5;
My_GREAT_COUNTER = 4;
}
(the program does not do anything useful... My goal is to extract the variable names their location where they are being declared and their memory address)
When I compile the program I get the file a.out which is an elf file containing debug information.
Someone on the company wrote a program in .net 5 years ago that will get all this information from the a.out file. This is what the code returns:
// Name Display Name Type Size Address
For this small program it works great and also for other large projects.
That code is 2000 lines long with several bugs and it does not support .NET version 4. That's why I am trying to recreate it.
So my question is, I am lost in the sense that I don't know what approach to take in order to solve this problem. These are the options I have been considering:
Organize the buggy code of the program I showed on the first image and try to see what it does and how it parses the a.out file in order to get that information. Once I fully understand it try to figure out why it does not support version 3 and 4.
I am ok at creating regex expressions so maybe try to look for the pattern in the a.out file by doing something like: So far I was able to find the pattern where there is just one file (main.c). But when there are several files it get's more complicated. I haven't tried it yet. Maybe it will be not that complicated and it will be possible to find the pattern.
Install Cygwin so that I can use linux commands on windows such as objdump, nm or elfread. I have't played enough with the commands when I use those commands such as readelf -w a.out I get way more information that I need. There are some cons why I have not spend that much time with this approach:
Cons: It takes a while to install cygwin on windows and when giving this application to our customers we don't want them to have to install it. Maybe there is a way of just installing the commands objdump and elfread without having to install the whole thing
Pros: If we find the right command to use we will not be reinventing the wheel and save some time. Maybe it is a matter of parsing the results of a command such as objdump -w a.out
In case you want to download the a.out file in order to parse it here it is.
Summary
I will to be able to get the global variables on a.out file. I will like to know what type each variable is (int, char, ..), what memory address they have and I will also like to know on what file the variable is being declared (main.c or someOtherFile.c). I will appreciate if I don't have to use cygwin as that will make it more easy to deploy. Since this question asks for a lot, I attempted to split it into more:
objdump/readelf get variables information
Get location of symbols in a.out file
perhaps I should delete the other questions. sorry being redundant.
Here is what I will do. Why reinvent the wheel!
Download linux commands that will be needing on windows from here.
on the bin directory there should be: readelf.exe
Note we will not need Cygwin or any program so deploying will be simple!
Once we have that file execute in cmd:
// cd "path where readelf.exe is"
readelf.exe -s a.out
and this is the list that will come out:
so if you take a look we are interested in getting all the variables that are of type OBJECT with size greater than 0.
Once we got the variables we can use the readelf.exe -w a.out command to take a look at the tree and it looks like: let's start looking for one of the variable we found on step 2 (SOME_GREAT_COUNTER) Note that at the top we know the location where the variable is being declared, we got more information such as the line where it was declared and the memory address
The last thing we are missing to do is to get the type. if you take a look we see that the type is = <0x522>. What that means is that we have to go to 522 of the tree to get more info about that time. If we go to that part this is what we get: From looking at the tree we know that SOME_LARGE_VARIABLE is of type unsigned long
I have some C source files that need to be pre-processed so that I can use another application to add Code Coverage instrumentation code in my file.
To do so, I use GCC (I'm using this on a LEON2 processor so it's a bit modified but it's essentially GCC 3.4.4) with the following command line:
sparc-elf-gcc -DUNIT_TEST -I. ../Tested_Code/0_BSW/PKG_CMD/MEMORY.c -E > MEMORY.i
With a standard file this works perfectly, but this one the programmer used a #ifndef UNIT_TEST close and no matter what I do the code won't be pre-processed. I don't understand why since I'm passing -DUNIT_TEST to GCC explicitly defining it.
Does anyone have any clue what could cause this? I checked the resulting .i file and as expected my UNIT_TEST code is not present in it so I get an error when instrumenting it.
Anything wrapped in an #ifndef will only be parsed if it's NOT defined so you need to remove that definition to get all the code that is inside that block. GCC can't spit out preprocessed info for all the #ifdef and #ifndef if at preprocessing times symbols are/aren't defined.
I am trying to set the sys exit call to a variable by
extern void *sys_call_table[];
real_sys_exit = sys_call_table[__NR_exit]
however, when I try to make, the console gives me the error
error: ‘__NR_exit’ undeclared (first use in this function)
Any tips would be appreciated :) Thank you
Since you are in kernel 2.6.x , sys_call_table isnt exported any more.
If you want to avoid the compilation error try this include
#include<linux/unistd.h>
however, It will not work. So the work around to "play" with the sys_call_table is to find the address of sys_call_table in SystemXXXX.map (located at /boot) with this command:
grep sys_call System.map-2.6.X -i
this will give the addres, then this code should allow you to modify the table:
unsigned long *sys_call_table;
sys_call_table = (unsigned long *) simple_strtoul("0xc0318500",NULL,16);
original_mkdir = sys_call_table[__NR_mkdir];
sys_call_table[__NR_mkdir] = mkdir_modificado;
Hope it works for you, I have just tested it under kernel 2.6.24, so should work for 2.6.18
also check here, Its a very good
http://commons.oreilly.com/wiki/index.php/Network_Security_Tools/Modifying_and_Hacking_Security_Tools/Fun_with_Linux_Kernel_Modules
If you haven't included the file syscall.h, you should do that ahead of the reference to __NR_exit. For example,
#include <syscall.h>
#include <stdio.h>
int main()
{
printf("%d\n", __NR_exit);
return 0;
}
which returns:
$ cc t.c
$ ./a.out
60
Some other observations:
If you've already included the file, the usual reasons __NR_exit wouldn't be defined are that the definition was being ignored due to conditional compilation (#ifdef or #ifndef at work somewhere) or because it's being removed elsewhere through a #undef.
If you're writing the code for kernel space, you have a completely different set of headers to use. LXR (http://lxr.linux.no/linux) searchable, browsable archive of the kernel source is a helpful resource.
I'm using tempnam() only to get the directory name, so this security warning does not apply to my case. How can I disable it? I couldn't find any switches to do it.
If you really only want the directory name, use the string constant macro P_tmpdir, defined in <stdio.h>.
"The tempnam() function returns a pointer to a string that is a valid filename, and such that a file with this name did not exist when tempnam() checked."
The warning arises because of the race condition between checking and a later creating of the file.
You want to only get the directory name? What should that be good for?
Like stranger already said, you may disable this (and similar warnings) using -Wno-deprecated-declarations.
The answer is no, because - on many systems - the GNU C library (glibc) which implements this function is compiled so as to trigger a linker warnings when it is used.
See:
GCC bug page regarding this issue - I filed this a short while ago.
GNU ld bug page regarding this issue - filed in 2010!
GNU ld bug page suggesting an approach for resolving the issue - I filed this a short while ago.
Note that the problem is not specific to GCC - any linker is supposed to emit this warning, its trigger is "hard-coded" in the compiled library.
If you want to create a temporary directory that's unique for the process, you can use mkdtemp.
This can, e.g., be useful to create FIFOs in there, or when a program needs to create lots of temporary files or trees of directories and files: Then they can be put into that directory.
As linker warning it may be obfuscated by using this answer's ASM workaround/hack:
https://stackoverflow.com/a/29205123/2550395
Something like this (quick and dirty):
#include <stdio.h>
#include <fcntl.h>
#include <sys/stat.h>
char my_file[20];
#define __hide_section_warning(section_string) \
__asm__ (".section " section_string "\n.string \"\rquidquid agis prudenter agas et respice finem \"\n\t.previous");
/* If you want to hide the linker's output */
#define hide_warning(symbol) \
__hide_section_warning (".gnu.warning." #symbol)
hide_warning(tmpnam)
tmpnam( my_file );
lock_fd = open( my_file, O_CREAT | O_WRONLY, (S_IRUSR | S_IWUSR | S_IRGRP) );
However, it still will leave a trace in the Make.p file and therefore isn't perfectly clean, besides already being a hack.
PS: It works on my machine ¯\_(ツ)_/¯
You can use GCC's -Wno-deprecated-declarations option to disable all warnings like this. I suggest you handle the warning properly, though, and take the suggestion of the compiler.