I'm debugging the goldfish android kernel (version 3.4), with kernel sources.
Now I found that gdb sometimes jump back and forth between lines, e.g consider c source code like the following:
char *XXX;
int a;
...
if (...)
{
}
When I reached the if clause, I type in n and it will jump back to the int a part. Why is that?
If I execute that command again, it would enter the brackets in the if.
If possible, I want to avoid that part, and enter the if directly (of course, if condition matches)
When I reached the if clause, I type in n and it will jump back to the int a part. Why is that?
Because your code is compiled with optimization on, and the compiler can (and often does) re-arrange instructions of your program in such a way that instructions "belonging" to different source lines are interleaved (code motion optimizations attempt (among other things) to move load instructions to long before their results are needed; this helps to hide memory latency).
If you are using gcc-4.8 or later, build your sources with -Og. Else, see this answer.
Related
So I'm emulating an extra instruction in C for the MSP440 called IFcc, where cc is the condition. How it works is if the condition is true, then the 'true instructions' are executed, and the 'false instructions' are skipped, and vice versa if the condition is false. The instruction takes two arguments, TC which is the number of instructions to execute if condition is true, and FC which is the number on instructions to execute if the condition is false.
Here is an example of what the assembly code might look like:
CMP &ALPHA,&BETA
IFEQ 2,2 ; Execute the first and second instructions if ALPHA = BETA
; or the third and fourth instructions if ALPHA BETA
MOV #0,&ALPHA ; Executed if ALPHA = BETA
MOV #1,&BETA ; Executed if ALPHA = BETA
MOV &BETA,&ALPHA ; Executed if ALPHA ≠ BETA
ADD #1,&ALPHA ; Executed if ALPHA ≠ BETA
What I'm having trouble figuring out, is how to ignore the instructions that should not be executed. The assembly itself wouldn't be changed to use branches, because the point of the IFcc instruction is to eliminate the necessity for branches. Any help with this would be greatly appreciated.
I dont recognize that instruction, is this an instruction you are inventing within your emulator?
Assuming that is the case
The msp430 instruction set is variable word length so if you want the logic to simply say do or dont execute the next two instructions, you have to specify instructions, but you wont know until the first words of each are decoded to know how many words that is, but that doesnt matter you put a counter in and count down the number of instructions, and simply dont do the execute or write back stages of the pipe.
at the end of the day all you are doing here is a branch on condition or branch on not condition, how is this instruction different? not flushing the pipe vs flushing the pipe? who is to say that a branch flushes the pipe in current/modern designs, if the branch is near enough and the pipe is deep enough there may be an optimization in the design to not flush and refill but to instead just keep going and skip (for the very common cases where the branch is forward by some small number of words).
the simplest is to just branch, set the pc to the word after the instructions skipped, you should have already implemented this in a branch, but the ASSEMBLER should be the one responsible for computing how many words there are in the next N instructions. It may be that a skip two instructions in one case is skip over two words (add 4 to the pc) or it could elsewhere mean that skip over two instructions means skip 5 words. Just like the implementation of a branch where you specify a label and the assembler takes care of making multiple passes and finally computing the offset to where the label would be in the instruction flow. which basically means make this a branch with a label.
if you dont want to make this a branch with a label then you have to pretend to execute the next N instructions to the point that you decode them enough to know how many words wide they are and skip that many words, repeat for the number of instructions to skip. runtime there is no other way to do it.
It turned out I needed to just prevent the instruction from writing back to memory by putting some conditions around the memory write function. Depending on the state of the machine (unconditional , true condition, false condition), which would be set by IFcc, it would either write to memory or be prevented from writing to ememory
With reference to this:
calculating FLASH utilisation by C code
I have decided to check the calculations of actual assembly instructions.
so my script counts the assembly instructions, lies in the assembly listing file of the feature enable code.
e.g.
if(TRUE == feature1_enable)
{
// instruction counting starts here
doSomething;
.
.
.
// instruction counting stops here
}
This gives me some counts x from which I can figure out the size of the code.
To cross check the result I decided to nm the object file of the feature code but nm gives the size of entire function and not the individual statements.
So I copied the code part for that feature in separate file, made the function of it, included necessary headers and declared variables to get this file compile (by taking care of locals would remain locals and globals would remain globals).
so the new file looks like this:
#include "header1.h"
#include "header2.h"
global_variables;
void checkSize( void )
{
local_variables;
// feature1_enable code
doSomething;
.
.
.
}
Now the function checkSize contains only the feature enable code so after compiling, if I nm the obj file, I should be able to get almost same result as assembly counts (apart from some extra size utilized by the function setup).
But that not the case, I have received huge difference. (1335 bytes in the case of assembly instructions and 1458 bytes in the case of nm of obj file).
To get the further clarification, I have created assembly of the file with function checkSize and compared with original assembly file.
I understand there is some extra stuff due to the addition of checkSize function but instructions of the feature enable code expected to be same (with the same compiler optimization and other options).
But they were not the same.
Now the question is why is there such difference in the assembly instructions for feature code inside big function and when I move it to the other file with the feature code alone.
Is there anything to predict the extra size in either case?
There could be several things happening here. To be sure you are going to have to read the actual assembly code and figure out what it is doing. The compiler is VERY clever when you have it set to a high optimization level. For example in your first code segment it is very possible for the compiler to have assembly statements out side of your
// instruction counting starts here
// instruction counting stops here
comments that perform work in between the comments. In your second example that optimization is not possible and all work needs to be done in the function. Also do not discount the amount of space the prolog and epilog of functions take. Depending on the instruction set of your processor and its stack and register usage it can be quite large. For example on Power PC there is no push many registers instruction and you have to push each individual register and pop each individual register off of the stack frame when enter and leaving a function. When you're dealing with 32 registers that can be quite a bit of code.
You could try a trick when you have high optimization levels set for you compiler. The compiler cannot optimize across "asm" statements as it does not know what happens in them. What you could do is put some dummy code in the "asm" statements. I personally like creating global symbols that are in the object file. That way I can get the address of the starting symbol and ending symbol and calculate the size of code in between. It looks something like this...
asm(" .globl sizeCalc_start");
asm(" sizeCalc_start: ");
// some code
asm(" .globl sizeCalc_end");
asm(" sizeCalc_end:");
Then you can do something in a function like
extern int sizeCalc_start;
extern int sizeCalc_end;
printf("Code Segment Size %d\r\n", &sizeCalc_end - &sizeCalc_start);
I've done this in the past and it worked. Have not tried to compile this so dunno you may need to mess around with it a bit to get what you want.
Optimization is tricky. Within a big function (and the big file) the compiler has wider context, and may optimize more aggressively - reuse common expressions, pick shorter forms of branches, etc (hard to say exactly without knowing your target architecture).
PS: I am not quite sure how do you go from assembly count to the byte count.
I was writing a program to input a string and output alternate characters in the string and I could compile it once, and building it made my antivirus program report that it is a virus (Gen:variant.graftor.74557).
Does any of my code causes something malicious to be called a virus
#include<stdio.h>
#include<string.h>
void altchar()
{
char a[50];
printf("Enter a string");
gets(a);
int i=0;
for(i=0;i<strlen(a);i+=2)
printf("%c",*(a+i));
}
int main()
{
altchar();
return 0;
}
Other c programs compiles very smoothly with no clashes with my AV.
Update:
My AV has no problem with gets() function, and other programs that use gets works smoothly.
Update 2:
By the way, I can run the program exactly once, then it is moved to quarantine.
And the output is nothing and the compiler tells me
Process returned 1971248979 (0x757EDF53) execution time: -0.000 s
For curious minds, I use Bitdefender Antivirus!
The "virus" detected is actually a placeholder name for the F-Secure generic trojan detector. It looks into programs for suspect behaviour. Unfortunately that kind of analysis is bound to sometimes producing false positives.
Maybe your harmless code matches some known malware behaviour on a byte code level? Try making a small change to your code and see if the problem goes away. Otherwise you can submit your program (info on the paged linked above) as a false positive to help them improve their database.
The classic methodology of an antivirus software is to take a few bytes (very well chosen bytes) from an infected file and use those as an identifier string ... it searches the executables and if the bytes match with some bytes from an executable (this check is most of the time done when opening (running) an executable, or when performing a full system scan) then it marks it as a virus.
Fix your code (as per comments), and recompile ... see what happens :)
When I try to debug my C program, and even before the compiler starts executing any line I get:
"Unhandled exception at 0x00468867 in HistsToFields.exe: 0xC00000FD: Stack overflow."
I have no clue on how to spot the problem since the program hasn't even started executing any line (or at least this is what I can see from the compiler debugging window). How can I tell what is causing the overflow if there isn't yet any line of my program executed?
"The when the debugger breaks it points to a line in chkstk.asm"
I'm using Microsoft Visual Studio 2008 on a win7.
I set the Stack Reserve Size to 300000000
PS: the program used to execute fine before but on another machine.
I have a database (120000 x 60)in csv format, I need to change it to space delimited. The program (which I didn't write myself) defines a structure of the output file:
`struct OutputFileContents {
char Filename[LINE_LEN];
char Title[LINE_LEN];
int NVar;
char VarName[MAX_NVAR][LINE_LEN];
char ZoneTitle[LINE_LEN];
int NI;
int NJ;
int NK;
double Datums[MAX_NVAR];
double Data[MAX_NVAR][MAX_NPOINT];`
This last array "Data[][]" is what contains all the output. hence is the huge size.
This array size "MAX_NPOINT" is set in a header source file in the project, and this header is used by several programs in the projects.
Thank you very much in advance.
Ahmad.
First, IDE != compiler != debugger.
Second, and no matter why the debugger fails debugging the application - a dataset that huge, on the stack, is a serious design error. Fix that design error, and your debugger problem will go away.
As for why the debugger fails... no idea. Too little RAM installed? 32bit vs 64bit platform? Infinite recursion in constructing static variables? Can't really say without looking at things you haven't showed us, like source, specs of environment, etc.
Edit: In case the hint is missed: Global / static data objects are constructed before main() starts executing. An infinite (or just much-too-deep) recursion in those constructors can trigger a stack overflow. (I am assuming C++ instead of C as the error message you gave says "unhandled exception".)
Edit 2: You added that you have a "database" that you need to convert to space-delimited. Without seeing the rest of your code: Trying to do the whole conversion in one go in memory isn't a good idea. Read a record, convert it, write it. Repeat. If you need stuff like "longest record" to determine the output format, iterate over the input once read-only for finding the output sizes, then iterate again doing the actual conversion.
How to protect c++ output file(pe file) from editing using crc(Cyclic Redundancy Check)?
**Best Regards**
You can use CRC's to effectively check to see if a file was accidentally altered, but they are not effective for copy protection, or preventing cheats on a game.
Usually, when I program has some sort of CRC check, I find the code which does the check, and change the assembly instruction from a conditional branch to an unconditional branch. This is usually quite easy to find, because normally after a CRC fail, the program displays a message and exits. I place a break point when the message occurs, and examine all the frames in the stack. I then put break points on each point in the stack, run the program again, and see which one does the CRC check.
This isn't particularly difficult, and people often bundle little programs which will apply the same changes to the software of your choice.
You need a static variable in your code. The variable needs to be initialized to a value that can easily found with an hex editor (e.g. DEADBEEF)
you need a crc-algorithm (try searching google)
The tricky part. You need to get pointer in memory to the start and to the end of your exe. You can parse the pe file header for the code location and run the crc-algorithm from start of code to end of code. Then you have the value.
Of course you have to check the calculated value with the one in the static variable.
Inserting the value - depending on how often you build, you might want to programm a tool. You can always run your program and set a breakpoint on the comparison. Then you note down the value and hex-edit it into the executable. Or you create a standalone program that parses the pe-header as well, uses the same function (this time on the file) and patches it in. This could be complicated though, because I don't know what is changed by the OS during loading.