As I said in another thread, I successfully compiled a new KOS 2.0 toolchain based on GCC 4.8.2 under MinGW environment.
My questions are about GDB. I'm using the latest GDB available which is the 7.9 at this time.
I created a sample program gdb_sample.c where I'm calling the gdb_init() func at startup.
I compiled this proggy with the -g switch to include debug symbols, then I run it through dcload-ip and starting the GDBserver with the -g switch.
Everything seems to be working, I can now debug my program with the help of sh-elf-gdb from my MinGW shell.
I have 3 questions:
1. Does I need to compile KOS with the -g switch in order to fully debug my program? I think yes.
2. Can the Makefile.rules file improved to manage Debug and Release configuration? I saw there is an 'dist' target which can strip symbols. So can I say that the 'all' target is making a Debug config and the 'dist' the Release's one?
3. When I start the GDB with the new GDB/MI interface, the main thread execution stack reported by GDB is completely wrong.
For example, consider the following program (this isn't the real program, I'm writing it from my remembers):
Code: Select all
1 // WARNING NOT THE REAL PROGRAM
2
3 #include <kos.h>
4 #include <arch/gdb.h>
5
6 // romdisk startup macros...
7
8 int test(int a) {
9 return a + 5;
10 }
11
12 int main(int argc, char* argv[]) {
13 gdb_init();
14
15 int x = 0;
16
17 x++;
18 printf("%d\n", x);
19
20 x++;
21 printf("%d\n", x);
22
23 x = test(x);
24 printf("%d\n", x);
25
26 return 0;
27 }
28
When the end of the program execution is reached, GDB crashes with the following message:
Code: Select all
inferior_thread: Assertion `tp' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) [answered Y; input not from terminal]
I found another topic about this issue, but in a more close context of mine. Marc Khouzam is replying that the GDBserver proggy must be the same version of the used GDB. Since I'm using GDB 7.9, maybe the GDBserver included in dcload-ip is pretty old and that's why it crashes at the end plus why the execution thread is completely messed up?
Thank you for reading me.
Mike