GDB on desktop??

[iru]

Lazarus 0.0.26.2, fpc 2.2.2, winCE, operating environment Win32.

GDB failed to start when compiling/executing a winCE project.

Examining the View>Debug windows>Debug output I see that lazarus is expecting GDB to
be on the desktop:

C:\Documents and Settings\Ian Upton\Desktop>gdb --tui c:\projects\lazarus\TrackIt-PDA\project1.exe --directory=c:\projects\lazarus\TrackIt-PDA 

I thought the path to gdb would be controlled by the settings in Environment>Options>Debug>General>"Debug type and path".

Putting gdb and the wince stub on the desktop enabled gdb but this is ugly.....

Any help appreciated, Ian.

[Marc]

C:\Documents and Settings\Ian Upton\Desktop>gdb --tui c:\projects\lazarus\TrackIt-PDA\project1.exe --directory=c:\projects\lazarus\TrackIt-PDA

This is not a line generated by lazarus. First lazarus uses the mi interface (-i mi) second, it sets the working directory through the prompt and not in the command line.

[iru]

A little more help please. Where is the message generated??? I can find nothing on the "mi interface".

[Vincent Snijders]

How do you start gdb?

[iru]

Debug and GDB is selected by Environment>Options>Debugger>General>Type and path = GDB. The PATH setting appears to be ignored.

GDB is started at the end of the lazarus Compile-link sequence.

It is interesting GDB only starts ONCE per lazarus session. Load lazarus, compile-link and GDB starts. Close down the GDB window, compile-link and GDB does not start.

[Marc]

It should not be ignored. its the only way how lazarus knows what gdb to execute. So what is filled in there ?

[iru]

The Environment>Debugger>Type and path contained:

C:\SW\WinCE-Gnu-Debug\gdb-6.4-win32-arm-wince\gdb.bat.

The GDB.BAT contained the --tui :\projects\lazarus\TrackIt-PDA\project1.exe
                                      --directory=c:\projects\lazarus\TrackIt-PDA
which appeared in the View>Debug windows>debug display.

The paths and files are valid.

I changed the GDB.BAT to GDB.EXE and the following happened:

The gdb stub was loaded into the emulator (takes a lonnnnnng time), the program executed in the emulator.
The DOS window with the GDB TUI interface did not appear.
The View>Debug windows>debug display showed what appeared to be a log of debug type data.

I could remove GDB and the GDB STUB from the desktop,  the program loaded and executed in the emulator.

So it would appear that lazarus does like the GDB debugger wrapped in a .BAT file. Somehow from that it required GDB and the STUB on the desktop.

My new problem is what should really happen with regard to debug. How does the debug work with GDB and the ARM emulator?

Can I set breakpoints within the IDE???? Currently a "breakpoint" line of code has a "?" in the IDE display gutter.

Is the GDB TUI DOS window supposed to be displayed????

If I click on Run>stop and Run>Reset Debugger the "GDB" in the emulator complains of an error 10054 which indicates the IDE is communicating with the debug process. Unfortunately the IDE then gives an "access violation" error message.

There are numerous explanations of how to use GDB with Lazarus and the emulator on the internet with varying levels of completenes and accuracy. Using GDB and TUI I have problems with line numbers and breakpoints.

What should I be able to do in the Lazarus IDE environment when debugging an ARM program in the emulator?????????

Ian

[Marc]

The Environment>Debugger>Type and path contained:

C:\SW\WinCE-Gnu-Debug\gdb-6.4-win32-arm-wince\gdb.bat.

The GDB.BAT contained the --tui :\projects\lazarus\TrackIt-PDA\project1.exe
                                      --directory=c:\projects\lazarus\TrackIt-PDA
which appeared in the View>Debug windows>debug display.

I don't know where you got the .bat from but it sure is no part of lazarus.
Maybe you or someone else tried to debug your app outside lazarus.

The paths and files are valid.

I can imagine. IIRC tprocess only allows running "real" exes, not shell interpreted scripts

I changed the GDB.BAT to GDB.EXE and the following happened:

The gdb stub was loaded into the emulator (takes a lonnnnnng time), the program executed in the emulator.
The DOS window with the GDB TUI interface did not appear.

indeed, since lazarus doesn't use tui, you shouldn't see one

The View>Debug windows>debug display showed what appeared to be a log of debug type data.

I could remove GDB and the GDB STUB from the desktop,  the program loaded and executed in the emulator.

this is how it is supposed to work

So it would appear that lazarus does like the GDB debugger wrapped in a .BAT file. Somehow from that it required GDB and the STUB on the desktop.

From what do you concluse dat lazarus runs the debugger from a .bat ? When you changed the debugger path to a .exe it worked, with .bat not

My new problem is what should really happen with regard to debug. How does the debug work with GDB and the ARM emulator?

Can I set breakpoints within the IDE????

Yes

Currently a "breakpoint" line of code has a "?" in the IDE display gutter.

Does your exe have debug symbols. Do you strip the exe (don't) Do you use upx (don't)

Is the GDB TUI DOS window supposed to be displayed????

No, lazarus doesn't use tui

If I click on Run>stop and Run>Reset Debugger the "GDB" in the emulator complains of an error 10054 which indicates the IDE is communicating with the debug process. Unfortunately the IDE then gives an "access violation" error message.

In what case? running as exe or as bat ?

There are numerous explanations of how to use GDB with Lazarus and the emulator on the internet with varying levels of completenes and accuracy. Using GDB and TUI I have problems with line numbers and breakpoints.

don't use TUI

What should I be able to do in the Lazarus IDE environment when debugging an ARM program in the emulator?????????

Everything like setting breakpoints, inspect variables, stepping, runto etc.

Again... the .bat file is not part of lazarus. Someone else created that. don't use it.

[iru]

Thanks for the long and detailed response, now I understand a lot of things.

The .bat file was my idea based on examples of how to invoke gdb for wince I found while surfing for "lazarus wince debug.........".

Using just the .exe and being rather patient as the debug process is rather slow.

Now down to trying to debug ugly things like "TCustomForm.Show impossible".

Regards, Ian.

[iru]

GDB is working and I can breakpoint and step my way through the code. I am attempting to address a number of problems generally related to form display and access violation errors.

Taking the simplest case:

Main form displayed, click on button (ShowModal) - second form displayed (form is simple grid-datasource-memtable and an EXIT button).

Click on the EXIT button, second form closes, main form displayed correctly.
Click on button again to re-load the second form (ShowModal) and I get an access violation error and the message External: SigSegV in the lazarus IDE.

Click on the OK button and I get an "Assembler" form with assembler code.

Stepping through the Pascal code in the IDE results in odd errors at various places (different every time) therefore I would like to tackle the problem by working back from the assembler display (stops consistently at the same instruction).

What I need to know is where can I find a linker map of the ARM executable code so I can work back from the failure to module>code to either solve the problem or provide appropriate debug data to someone who can solve the problem.

Any help greatly appreciated, Ian

[Marc]

Backtraces from windows internal functions are sometimes difficult.
Anyway, the AV on second show of a form sounds like a classic error.
How do you create the second form ? And when closing it, is it destroyed ?

[iru]

With regard to the AV error on the second attempt to open the second window:

The second form is exited by a "Close" command which is executed on the click on the "Exit" button. The second form is not freed/deleted/released, the structure should still be there.

I originally created all the code in a win32 environment and then moved it to wince. In win32 I can load and exit the second form multiple times, NO AV error.

This is only one of a number of problems I need to resolve, as follows:

A third form (similar characteristics to the second (grid-datasource-memdata)) gets an AV error when the ShowModal is executed. Works OK in win32

In the second form the grid does not display the data in the memtable. Works OK in win32.

The problems with the second and third forms appear to be stopping at the same place in the assembler code. Given what you say about backtraces mapping the "assembler" crash location to a module>instruction by means of a linker load map may be the best method available to get further information on these type of errors. Somewhere there must be a map of the exectable arm code.

Ian

[Marc]

You can try to pass -Xm (Generate link map) as compiler option

[iru]

Once again thanks.

Found the .map file. Woops out of the frying pan into the fire......

Long time since I have delved into a linker map file, some things look vaguely familiar so I will try and work my way through it.

Ian

[dannydesiliva]

Ticking "Do not run the debugee" fixes it, kind of. When I click the continue button the run command is sent. Shouldn't it be "continue"?