3 questions about GDB

[SiZiOUS]

Hello,

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

The execution cursor is shown on the row 13, then row 17, 18, then 24, 21 and 26 (this's an example). The execution thread can't be done like that and I don't explain why GDB is reporting this.

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]

This message was reported here but there isn't link between my context and the one described in that bug report.

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

[BlueCrab]

I've personally never used GDB with KallistiOS, so I can't really answer some of the questions fully here. But, I can answer a few, so here goes...

1. Does I need to compile KOS with the -g switch in order to fully debug my program? I think yes.

It's the default to compile with debugging symbols, and as you suspect you really should in order to fully be able to debug as much about your program as possible. That said, unless you're trying to debug issues in KOS proper, KOS itself doesn't need to be compiled with -g.

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?

Generally, that is indeed the case.

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

The execution cursor is shown on the row 13, then row 17, 18, then 24, 21 and 26 (this's an example). The execution thread can't be done like that and I don't explain why GDB is reporting this.

I can't say for sure, but in order to truly debug a program, you should really compile it with -O0 to turn off all optimizations. It's possible that the compiler has optimized the code in such a way that it actually does execute in a weird loopy pattern as you've described it. After all, the compiler is only worried about getting the correct result. Also, it's possible that GCC has just spit out code that doesn't work properly.

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]

This message was reported here but there isn't link between my context and the one described in that bug report.

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?

Anything about GDBserver is irrelevant here. We don't actually use any sort of official GDB server. All dcload does is ferry the messages along to the KOS program with a special packet. I can't actually answer what the problem is, as I don't use GDB, as I said before... Being that this happens when the program exits, I'd imagine it's pretty much harmless though. You probably should answer 'n' to the prompt though, unless you intend to debug gdb itself.

[SiZiOUS]

Thanks for all your answers BlueCrab.

I'll try to disable all the compiler optimizations in order to see if the weird execution thread path occurs.

For the GDB 'bug', OK, I think i'll make a little workaround then.
I just saw that when I kill the GDB executable at the end of the execution, it's OK, and this don't bother me.
So there isn't GDB server at all then? That's why I wasn't able to find some GDB server reference in dcload.

Btw, why you don't use GDB? It's a nice piece of software and really useful.

[BlueCrab]

GDB's kinda weird when dealing with remote debugging to start with. Then you add in the additional muddling that dealing with dcload/dc-tool in the middle adds and it makes things even more confused.

As for why I don't use it on Dreamcast... I've just never found a reason to go through all the trouble of getting things set up. Plus, most of the things I've had to do any real hard debugging on are either timing dependent (i.e, video related stuff), or are related to the network stack (which would obviously be in-use to do GDB), so it's been a bit inconvenient to even think about using GDB.

I've used GDB (and more recently LLDB) on stuff on non-Dreamcast platforms often enough to know what a useful tool it can be. I've just never found a compelling use for it in debugging my Dreamcast stuff.