Pelles C forum

Pelles C => General discussions => Topic started by: cb951303 on July 12, 2005, 07:41:17 PM

Title: newbie needs a little help about debugger
Post by: cb951303 on July 12, 2005, 07:41:17 PM
hi guys, this is the first time I use debugger, so I'm sorry if I say something stupid,

I have 2 questions about debugger,

1-In my current project options, debug info is "FULL" but when ever I start the debugger it says
EDIT: OK! IT SEEMS THAT I HAVE TO SET DEBUG INFO FOR LINKER :) SORRY! BUT I STILL NEED HELP WITH 2. QUESTION

Code: [Select]

the file "xxxxx" contains no debugging information


2-In debugging mode, I can't see "debugging tabs" except if there is a crash in the app.(I think this is the same reason why occurs my first problem :) EDIT: APPARENTLY NOT!)
Title: Re: newbie needs a little help about debugger
Post by: Pelle on July 13, 2005, 12:20:56 PM
Quote from: "cb951303"
EDIT: OK! IT SEEMS THAT I HAVE TO SET DEBUG INFO FOR LINKER :)

Yes, this can be confusing in the beginning. In the Add-In SDK there is a sample that simplifies switching between debug and release builds. Maybe you want to install this SDK - just to make it easier...?

Quote from: "cb951303"

2-In debugging mode, I can't see "debugging tabs" except if there is a crash in the app.(I think this is the same reason why occurs my first problem :) EDIT: APPARENTLY NOT!)

Hmm. The tabs should be "activated" on the first break in the program. If you havn't set a breakpoint in a source file, this should be on entry to "main", "WinMain" or the module start address (if "main" or "WinMain" can't be found). If you have set a breakpoint before you start the debugger - we hope the program reaches this point!

Pelle
Title: newbie needs a little help about debugger
Post by: Anonymous on July 13, 2005, 02:48:24 PM
Quote
Hmm. The tabs should be "activated" on the first break in the program.


to be sure, I set breakpoints in every line :)
still I can't see debugging tabs...

PS:I'm working with sdl and opengl, maybe it gots something to do with it...
Title: newbie needs a little help about debugger
Post by: frankie on July 13, 2005, 04:51:40 PM
SDL main is not in your code (see http://smorgasbordet.com/phpBB2/viewtopic.php?t=648).
Probably this is the reason for missing break to program entry.
F.
Title: newbie needs a little help about debugger
Post by: cb951303 on July 14, 2005, 11:59:21 AM
Quote from: "frankie"
SDL main is not in your code (see http://smorgasbordet.com/phpBB2/viewtopic.php?t=648).
Probably this is the reason for missing break to program entry.
F.

oh! so how am I supposed to debug a SDL app.??
Title: newbie needs a little help about debugger
Post by: frankie on July 14, 2005, 12:39:17 PM
Quote from: "cb951303"
oh! so how am I supposed to debug a SDL app.??


Of course You don't have to. I just meant that if the debugger doesn't automatically break the app at the main entry point is becouse the main is defined elsewhere.
So you have to set your breakpoints manually. I have also experienced the problem debugging tabs problem, it seems that if the app to debug is not fully built under PELLESC the debugger have problems setting breakpoints. Anyway you can solve this with brute force coding (with the asm keyword) an INT 03 instruction. this will trap the break.

Pelle, in your superlative compiling system the debugger is the only point that probably need some further improvement! =D>
Title: newbie needs a little help about debugger
Post by: Pelle on July 14, 2005, 01:55:00 PM
Quote from: "frankie"
Pelle, in your superlative compiling system the debugger is the only point that probably need some further improvement! =D>

Can you please explain some more? What exactly are you missing?

Pelle
Title: newbie needs a little help about debugger
Post by: frankie on July 14, 2005, 04:56:47 PM
Quote from: "Pelle"
Quote from: "frankie"
Pelle, in your superlative compiling system the debugger is the only point that probably need some further improvement! =D>

Can you please explain some more? What exactly are you missing?

Pelle


Pelle, I like very much your system, but while debugging I miss some functionalities like a function to skip actual routine (so debug continues from the caller), also the possibility to break the execution and get back to the closest point in the sources (actually the execution don't stop, and if you scroll the source the whole window becomes blank  :( !).
Anyway great job :wink:
F.
Title: newbie needs a little help about debugger
Post by: Pelle on July 14, 2005, 08:34:08 PM
Quote from: "frankie"
Pelle, I like very much your system, but while debugging I miss some functionalities like a function to skip actual routine (so debug continues from the caller), also the possibility to break the execution and get back to the closest point in the sources (actually the execution don't stop, and if you scroll the source the whole window becomes blank  :( !).

There are always things to improve - I just wanted to hear some more about what you were missing.

Step out of function should be doable. Not sure about the best approach - could possibly be somewhat slow...

The "Break" command (Debug menu) usually works for me. As long as the debuggee is running, there will be no screen updates in the debugger (just a blank screen).

Pelle
Title: newbie needs a little help about debugger
Post by: frankie on July 15, 2005, 11:10:48 AM
Pelle,
basically I would like a more effective management of the breakpoints, and specifically the possibility to break the running program, this works but not always. If my code runs away inside function calls many times happen that I'm not able to know where it is executing and I have to abort the debug session (by aborting the process under debug), then restart de debbugging session and follow step by step the whole code until I reach the code loop. You understand that if the code is very deep and/or there are a lot of setting to give to the debbuged process to reach the point, the whole procedure becomes exhausting. Moreover the dynamic setting of breakpoints isn't very effective, many times adding a breakpoint while the process is running give no guarantee that it will be executed (still a big mess when you are following a random bug), so you don't know if execution is not tracing that part or you are simply missing the break. Eventually if you restart the debbugging happen to receive an error advice about the impossibility to set a previously issued breakpoint.
Now my wishes list:
- A tracing option to run out of a function (in case of you enter the debug of a big loop or any kind of time consuming code)
- A tracing option to run up to the cursor
- To choose the visualization format for the memory (byte, word, dword, float,...., or event data formats structs etc)
- To display memory at register address (specify EAX, EDX, ESI....)
- When breaking the execution if it is outside our code to have an assembler view of instructions instead of blank screen
- A dialog for breakpoints management that permits to change, set, reset breakpoints, even showing the list of the available functions to wich a break is applicable (same database of project symbols)

Pelle consider that when you start a debbugging session is always when you are in a high stress phase for a bug that is not easily deduced by logical discerning, and generally late at night......
Thank-you very much for your help and support.
F.
Title: newbie needs a little help about debugger
Post by: Ngan Lo on July 15, 2005, 02:07:13 PM
Quote from: "Pelle"
Step out of function should be doable. Not sure about the best approach - could possibly be somewhat slow...

Pelle man, step out from a function which was "Step into..." is very important, i always want the debugger continue the step after i finished 'step into a function', is it only me need this ??!  :oops:

this is really my only wish on wish-list.  8)  :mrgreen:
Title: newbie needs a little help about debugger
Post by: Pelle on July 15, 2005, 07:07:23 PM
Quote from: "frankie"

basically I would like a more effective management of the breakpoints, and specifically the possibility to break the running program, this works but not always.


Breaking the debuggee isn't trivial. The most reliable way I have found is to use CreateRemoteThread() and use DebugBreak() as the function to execute. On XP this can be simplified to DebugBreakProcess(). The process usually stops OK (Win 95/98/Me might as usual be more problematic). This means the process will be stopped in DebugBreak().

The only other way I could do this, is to single-step the processor, and look for a break request after every assembler instruction in the debuggee. Would work great, except it would take "forever".

All project breakpoints will be listed on a separate tab in v4.0, where you can disable them, or change conditions (pass-count etc.).

Quote from: "frankie"

Moreover the dynamic setting of breakpoints isn't very effective, many times adding a breakpoint while the process is running give no guarantee that it will be executed (still a big mess when you are following a random bug), so you don't know if execution is not tracing that part or you are simply missing the break. Eventually if you restart the debbugging happen to receive an error advice about the impossibility to set a previously issued breakpoint.

You can't add breakpoints while the process is running! You can toggle breakpoints in a source code window while debugging, but this doesn't help, since breakpoints are only moved to the debugger when it's started. In v4.0 you will only be able to toggle breakpoints in the debugger window (and as before, only when the process is paused).

Setting breakpoints in a source code window is unfortunately not an exact science. I don't know which lines will actually generate code, so I accept breakpoints everywhere. The debugger will only see source lines with some code attached - if it finds a breakpoint on some other line, it will complain. (Moving such breakpoints to the closest line might not always be a good idea because of "hidden" jumps, which will change the meaning).

Quote from: "frankie"

Now my wishes list:
- A tracing option to run out of a function (in case of you enter the debug of a big loop or any kind of time consuming code)

I have added this, but limited to the following:
a) You must be stepping out of a C function with debugging info (MASM code won't work).
b) The function must use, or be in the process of using, an EBP stack frame (should be OK for Pelles C compiled code, since the compiler will always produce EBP stack frames when debugging info is ON).

If the following conditions are met, I can read the return address from the stack and set a special (internal) breakpoint there.

Quote from: "frankie"

- A tracing option to run up to the cursor

OK - easy to add. I find it useless myself, but why not?

Quote from: "frankie"

- To choose the visualization format for the memory (byte, word, dword, float,...., or event data formats structs etc)

Since you can also edit the memory, viewing it in other formats seems confusing to me. Maybe in the future through some add-in support.

Quote from: "frankie"

- To display memory at register address (specify EAX, EDX, ESI....)

The address can be an expression in v4.0, and an expression can reference CPU registers, so this will work.

Quote from: "frankie"

- When breaking the execution if it is outside our code to have an assembler view of instructions instead of blank screen

If the debugger is paused, and I am allowed to read from the current address, AFAIK you should see at least assembly code...(?)

Quote from: "frankie"

- A dialog for breakpoints management that permits to change, set, reset breakpoints, even showing the list of the available functions to wich a break is applicable (same database of project symbols)

Breakpoint tab in v4.0. The project tree can be used. When the debugger window have focus, and you double-click on a function in the project tree, it should jump to that function (provided it's part of the debugging info).

Quote from: "frankie"

Pelle consider that when you start a debbugging session is always when you are in a high stress phase for a bug that is not easily deduced by logical discerning, and generally late at night......

Mmm. Briefly. ;-)
I don't think any software can handle this scenario gracefully... :-)

Pelle
Title: newbie needs a little help about debugger
Post by: Pelle on July 15, 2005, 07:09:06 PM
Quote from: "Ngan Lo"

Pelle man, step out from a function which was "Step into..." is very important, i always want the debugger continue the step after i finished 'step into a function', is it only me need this ??!  :oops:

this is really my only wish on wish-list.  8)  :mrgreen:

OK, it's added but with some limitations - see previous post.

Pelle
Title: newbie needs a little help about debugger
Post by: tiwag on July 15, 2005, 08:14:35 PM
@Pelle, what do you think about

I - Back-Trace-Log

II - memory-leakage-detection assistance

III - debug-log (user defined debug messages, logged into a file where the time & function name.line# is stamped too )

excuse me, when i'm "dreaming" - just brainstorming

--tiwag
Title: newbie needs a little help about debugger
Post by: Pelle on July 16, 2005, 12:05:14 AM
Quote from: "tiwag"
@Pelle, what do you think about
I - Back-Trace-Log

Could be useful - but would probably need a lot of work to be fast enough. Maybe need to single-step the processor for this. I have to think some more about this...

Quote from: "tiwag"

II - memory-leakage-detection assistance

Yes, very useful. Might need different approaches for dynamically and statically linked functions. Only malloc, realloc, free? - or also HeapAlloc, GlobalAlloc etc?

Another approach is having special "debug" libraries, but crt.lib, crtdbg.lib, crtmt.lib, crtmtdlg.lib, pocrt.lib, pocrtdbg.lib seems like too many variations to keep track of.

Quote from: "tiwag"

III - debug-log (user defined debug messages, logged into a file where the time & function name.line# is stamped too )

Well, you can do it "manually". Use OutputDebugString(), and after the debugger is finished, you still have a log in the Debug tab. Use Select all and Copy from the context menu, paste into a source window, and save as a text file. See - that wasn't so difficult...? :-)

Pelle
Title: newbie needs a little help about debugger
Post by: tiwag on July 16, 2005, 11:26:56 AM
Quote from: "Pelle"
Quote from: "tiwag"
@Pelle, what do you think about
I - Back-Trace-Log

Could be useful - but would probably need a lot of work to be fast enough. Maybe need to single-step the processor for this. I have to think some more about this...

surely, if you want to have a backtrace log into all system-dll's or even an assembler-mnemonic-level backtrace like in a real ICE ...

But in most cases it'll be sufficient, to have a function-call backtrace log for your own debug-coded functions and libraries. In this case you only have to maintain a function call table somewhere in the debuggers protected address-space, where one can look after a crash which have been the last called functions before the app crashed.
This system is implemented in a Hitachi SH8 IDDE and works great !
No big overhead, only one extra call inside every function (if it's a debug version), which evaluetes to nothing if compiled as Release.

Quote from: "Pelle"

Quote from: "tiwag"

III - debug-log (user defined debug messages, logged into a file where the time & function name.line# is stamped too )

Well, you can do it "manually". Use OutputDebugString(), and after the debugger is finished, you still have a log in the Debug tab. Use Select all and Copy from the context menu, paste into a source window, and save as a text file. See - that wasn't so difficult...? :-)

Pelle


well you're right, but think of an integrated debug-log where you provide as example the above backtrace-log too. all in one place and you can distribute your source code to other compilers too without have to mess with compiler specific stuff and macros.
Maybe you know the wxwidgets framwork - there the debuglog is a widely accepted and very well working thing for debug versions of an app.
Title: newbie needs a little help about debugger
Post by: Pelle on July 16, 2005, 06:35:40 PM
I don't understand.

The debug-log you described before sounds like an application thing - I don't see how it can affect the debugger very much. If it's suppose to be "compiler independent" shouldn't it also be "debugger independent"?

If you want the call tree after a crash, the "Call stack" tab should work. It does here.

Pelle
Title: newbie needs a little help about debugger
Post by: frankie on July 19, 2005, 10:26:11 AM
Thank-you very much Pelle. :D
I'aware that the managing of debug is not a simple thing.

Just as a matter of discussion what do you think of a third option on debugging where you introduce some debug control header in the stack frame creation?
The overhead is so limited to the function call and you could update some control data that will help to trace the code. Of course this modify the code lay-out, so maybe a bug present in the release code is not visible in debug mode and the reverse, but in general this help to find out some problems.
I would like to be of some help, but I never worked on this issue. Should I get aware of something interesting I'll advice you.
Thank-you again, and last question when do you think will be the version 4.00 available for Beta test?
F.
Title: newbie needs a little help about debugger
Post by: Pelle on July 19, 2005, 07:37:44 PM
Quote from: "frankie"
Just as a matter of discussion what do you think of a third option on debugging where you introduce some debug control header in the stack frame creation?

Depends on what you want to put in this header, or perhaps rather what you are missing at the moment.

Most info I can think of is available already - but without debugging info for Windows modules, for example, it's impossible to trace the stack through Windows. This will sometimes remove info that could otherwise be important...

Quote from: "frankie"

...when do you think will be the version 4.00 available for Beta test?

Not sure. I'm still coding - after that it's the help files, and so on. Several weeks or months, I would guess...

Pelle