|
Thanks, but I want to find a way that don't add any code like DEBUG_LOG(), to print source code.
because the source code too many. I wouldn't be do this otherwise.
|
|
|
|
|
This response shows that you have really no understanding of what a debugger does, and how to use it. A debugger does not require you to add anything to your code at all. There's no need for a debugger to print code, nor to add any code to your program.
You really should read this up before continuing to refuse the only sensible advice any experienced programmer can offer you on this problem: Debugger - Wikipedia[^]
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
The problem is I don't know where are the "condition is met".
Whether input's iVal is 1 or 2, first hundreds line code execution are equals. I want to find first diffence between 1 and 2 (iVal), and I sured the diffence appeared after "execution long line codes ago".
|
|
|
|
|
Hi,
You could use the Debug Interface Access SDK to get the exact line of 'source code' associated with any instruction offset in the executable. This is how WinDbg and Visual Studio knows where the line of source code is located.
Using your sample:
main()
{
int iTemp = 0; __asm int 3
fun()
iTemp = 1
}
Then add an exception hander for STATUS_BREAKPOINT (0x80000003) and call into DIA and pass the exception offset to get the source line.
It's actually quite simple.
However if you are looking to perform instrumentation at the instruction level then have a look at DynamoRIO and specifically the instrace_x86 sample.
Best Wishes,
-David Delaune
|
|
|
|
|
Using your method, I need add “__asm int 3;” for every line of code?
|
|
|
|
|
Member 13081369 wrote: Using your method, I need add “__asm int 3;” for every line of code?
No,
You could set the hardware breakpoints at DR0-DR7 and automate every single-step through your entire program printing out each line of source code as it is executed by querying the PDB file associated with the executable via DIA.
What you are asking is absolutely possible but it's a lot of work. Are you sure that you need to do this?
Best Wishes,
-David Delaune
|
|
|
|
|
First, I sure.
I run DIA SDK\Samples\DIA2Dump\Dia2Dump.exe myProgram.pdb
I can view values and functions list when Dia2Dump.exe is run.
But， How to "set the hardware breakpoints at DR0-DR7 and automate every single-step through your entire program"?
Is modify dia2dump.cpp -> main(), start my program by dia2dump.exe?
and WaitForDebugEvent(&dbgEvent, INFINITE); in dia2dump.exe?
Can you give me a sample?
|
|
|
|
|
Member 13081369 wrote: But， How to "set the hardware breakpoints at DR0-DR7 and automate every single-step through your entire program"?
With the SetThreadContext function. It would be a great learning exercise for understanding both debugging and exception handling.
Member 13081369 wrote: Can you give me a sample?
No,
But I thought of another way to do this automated that would not require modifying your source code. Dan Thompson has authored DbgShell which can be used from Powershell. With a simple powershell script you should be able to attach to your executable and single-step automated and then instantiate an IDiaDataSource object.
Again, like the other members responding to you... I can't imagine why you would want to print each line of source code.
Best Wishes,
-David Delaune
|
|
|
|
|
|
Why use the Visual Studio Debugger SDK, when you can just use the much more intuitive visual debugger that comes with the VS IDE? 
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
Hi Stefan,
The poster is asking "How do I print each source line into a text file as my program is being executed?"
Rather than belittle him I simply answered the question.
In fact I just thought of a much easier way to do this using Powershell with the Windbg COM interfaces and IDiaDataSource that doesn't require writing any code. He could just write a powershell script to automate it.
Best Wishes,
-David Delaune
|
|
|
|
|
Fair enough. I shouldn't have been so harsh.
That said, my experience tells me that people rarely want, literally, what they're asking for. If they're asking for something that requires even a modest amount of expertise, they likely have no good understanding of what is possible, or sensible, in the context of their problem. Therefore the first thing I usually do is question their real needs, or make an educated guess about it. Often I'm right, sometimes I'm wrong. But either way, I typically get a better understanding of what is really required after a response or two.
In this case, the OP is more adamant about what he needs than usual, but at the same time I'm convinced that answering his request, literally, won't really help him: His statement about not wanting to 'press F10 10000 times' implies two things:
1. that he does use a debugger
2. that he doesn't know how to use it for his particular problem
3. that he doesn't even expect that it can help him
(Ok, that's three, but the third is implied other than the quoted statements)
Unless I'm for some reason totally wrong with my interpretation, I feel that learning to use the debugger more efficiently is going to help a lot more than actually printing an exection log.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
Suppose you have a block in your code like:
static int someNumber = 100000;
...
for(int i = 0; i < someNumber; ++i)
{
int a = 0;
...
double b = (double )a++;
...
}
Now tell us how are you going to analyze those 20 * 100000 = 2 million lines of the executed code? 
|
|
|
|
|
struct stNode
{
union sss_ {
struct sns_ {
int iType;
float fType;
} s_name;
} s_ss;
stNode* pNext;
};
int FunA(stNode* pNode)
{
if (pNode->pNext->pNext->pNext->s_ss.s_name.iType>10)
{
...
pNode->pNext->s_ss.s_name.fType = 4.0f;
pNode->pNext = pNode->pNext + pNode->iType;
return pNode->pNext->pNext->s_ss.s_name.iType;
}
pNode->pNext = pNode->pNext + pNode->iType;
pNode->pNext->s_ss.s_name.fType = 7.0f;
...
return pNode->s_ss.s_name.iType;
}
main()
{
int iVal = 2;
for(int i = 0; i < 100; ++i)
{
iVal++;
stNode stMyNode;
if (iVal<100)
{
iVal = FunA(&stMyNode+iVal);
}
else
{
iVal = FunB(&stMyNode+iVal);
}
}
}
With difference iVal initialization. the difference of execution occured at hundreds lines run after begin of main().
And, the actual code of mine, are complex than above are. Very very complex, run one FunA()，need a lot of times. (many lines code)
|
|
|
|
|
Member 13081369 wrote: ... the actual code of mine, are complex than above are. Very very complex, run one FunA()，need a lot of times. (many lines code)
And how will you analyze such a "many lines code" in your "line output"? How much time would you need to just to look in this output?
|
|
|
|
|
If the code like below:
if(iVal < 10)
{
FunA();
}
else
{
FunB();
}
When first run, iVal=1. So the first.txt Should be:
if(iVal < 10)
FunA();
And second run, iVal=20. The second.txt Should be:
if(iVal < 10)
FunB();
I could compared two file(first.txt and second.txt) to find code execution difference.
I need it, because my codes very very larged. when iVal differeced every times, the differece appeard at after hundreds lines between first.txt and second.txt.
|
|
|
|
|
Member 13081369 wrote: I need it, because my codes very very larged. when iVal differeced every times, the differece appeard at after hundreds lines between first.txt and second.txt. |
1. What do you mean by "codes very very larged"? How many lines does it contain? 1000? 10000? 100000? One million?
2. Did you try to estimate how long would it take you to compare these "first.txt and second.txt"?
|
|
|
|
|
If you are using Visual Studio, you can use its integrated debugger. Here is a guide to get started with it - it's really easy: Get started with Visual Studio 2017 - Debugging[^]
If you are not using Visual Studio, you should tell us what you use, so someone can suggest a suitable debugger to use for that, and/or a quick guide to learn how to use it.
The important things to know about debugging:
1. if you don't want to, you do not need to add any specialized code to your program to enable debugging.
2. You can tell your debugger that you want your program to stop if something specific happens. What you told us is quite easy to specify with Visual Studio: you can make the program run up to exactly the point where your iVal changes (see Data Breakpoints – Visual Studio 2017 15.8 Update | Visual C++ Team Blog[^] )
3. When using a debugger, you can not only make your program run up to a point, you can also inspect all variables, the call stack, and other aspects of the current state of your program.
There are many more things that a debugger can help you with, e. g. change a variable at runtime, make the computer skip or repeat some code, etc.. All without changing the program code. But you have to learn the basics.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
How to change the background color of checkbox in CListCtrl?
The checkbox appears before the 1st column. if I change the background using m_cLstCtrl.SetBkColor(RGB(0,0,0)); the background of the entire control is changed.
If I change it inside OnCustomDraw as below:
void CSysWindow::OnCustomDrawAlarmLine ( NMHDR* pNMHDR, LRESULT* pResult )
{
NMLVCUSTOMDRAW *pCD = (NMLVCUSTOMDRAW*)pNMHDR;
// By default set the return value to do the default behavior.
*pResult = CDRF_DODEFAULT ;
//obtain row and column of item
int iRow = pCD->nmcd.dwItemSpec;
int iCol = pCD->iSubItem;
//Remove standard highlighting of selected (sub)item.
pCD->nmcd.uItemState = CDIS_DEFAULT;
switch( pCD->nmcd.dwDrawStage )
{
case CDDS_PREPAINT: // First stage (for the whole control)
{
*pResult = CDRF_NOTIFYITEMDRAW;
}
break;
case CDDS_ITEMPREPAINT:
{
*pResult = CDRF_NOTIFYSUBITEMDRAW;
}
break;
case CDDS_ITEMPREPAINT | CDDS_SUBITEM : // Stage three
{
if ((iCol != 0) || (iCol != 1))
{
pCD->clrText = RGB(255,0,0);
pCD->clrTextBk = RGB(0,0,0);
}
if ((iCol == 0) || (iCol == 1))
{
pCD->clrText = RGB(255,0,0);
pCD->clrTextBk = RGB(0,255,0);
}
//if (sub)item is of interest, set custom text/background color
//if( 1 == iRow && 3 == iCol )
//{
// pCD->clrText = RGB(255,0,0);
// pCD->clrTextBk = RGB(210,245,245);
//}
//else
//{
// pCD->clrText = RGB(0,0,0);
// pCD->clrTextBk = RGB(255,255,255);
//}
*pResult = CDRF_NOTIFYPOSTPAINT;
}
break;
case CDDS_ITEMPOSTPAINT | CDDS_SUBITEM: // Stage four (called for each subitem of the focused item)
{
}
break;
default:// it wasn't a notification that was interesting to us.
{
*pResult = CDRF_DODEFAULT;
}
break;
}
}
The background of the other column gets changed. but not the Checkbox.
So...How to change the background of the checkbox column alone?
|
|
|
|
|
Your code seems to be changing different columns. Try modifying the code so it only affects column 0 (where the checkbox is) and see what happens.
|
|
|
|
|
The complete background is not changing
|
|
|
|
|
Hi
1) I have huge C++ code, that I need to refactor. I am using RAD Studio- code gear
Please advise free Tool to refactor C++ code. Thanks you
2)The code is very bad. it has around 3000 compiler warning. I know it is bad to automate fixing the warnings  but Is there any tool, or automated process to fix the warnings
Thanks you!!
|
|
|
|
|
It is most unlikely that any tool could do this. You will need to get your "code analysis head" on and knuckle down to a few days (or weeks) of hard work.
|
|
|
|
|
The best tool is Elbow Grease and Visual Studio Level 4 warning level and "Stop on Warning" .
I'd rather be phishing!
|
|
|
|
|
A warning typically means that while the code is legitmate with respect to the C++ syntax, the compiler suspects that it might be doing something else than what the programmer intended. Since the computer can't guess what's in the head of the programmer, there's no safe way for it to automatically fix it.
If you have so many warnings, it's probably best to watch out for very common types of warnings, pick one of these, and focus on fixing that warning everywhere in the code, ignoring other warnings. Most of the time you'll quickly be able to spot certain patterns, and fixing these errors should therefore be possible almost without thinking after a while. It will still take time, but that way it's probably a lot faster than working on all warnings by order of occurrence.
P.S.: if your goal is refactoring the entire code, then eliminating warnings is the last of your concerns! First you need tests, to ensure that the refactored code really produces the same results. Then you need to start with the lowest level functions, and then work your way up. Chances are, that changes in your low level functions require adjustments higher up, and that could very well affect code that currently issues warnings. It would be pointless to fix warnings first and then change that same code again due to low-level refactoring, so you better don't do that so early!
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
modified 25-Jan-19 10:04am.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
