GDB related article for beginners.

If some of you in interst about GDB related article specific to aos4, there is

Big thanks to Xeron who correct all the english in the article, as well as rephrase some parts to make it reads better

Can you also make a article on how to get usefull info from grim crashlog?
Since i don't understand anything from a crashlog.

@Antique
Hanz already do it :) Check this out:

Using Crash-Logs for Debugging
Debug Logging on Amiga OS 4.x
Redirecting Debug Output to the Serial Port on Startup

@kas1e

Nice article.

@Antique
Quote:

This page gives you the basics of how to convert stack trace entries to line numbers.

Hans

@kas1e

Thanks for the article, will sure come in handy when i stumble over the next crash

@Hans

If i haven't thanked you yet for your great articles, i'll stand in shame...


...and thank you now

@Raziel
And also real-questions then come, with answer on which one more article can be done :)

does GDB work 100% as it should under os4 now?
or are there any limitations to be aware of?

@SpotUP
You still can crash it if you mean that :)

Well done, kas1e!

@kas1e and Xeron

Well done boys. Great job!

This should go into the SDK, IMO...

@elwood
Its too simple and too short to be in the SDK. And in general, it mostly for very-beginners, as those ones who works on GDB on any platform with any cpu , in general know that all of this "the same". SDK should have something really cool and professional, not something like this simply article :)

ps. have started one more about gdb, hope that one will be better and intersting

Kas1e, in that case, it didn't workfor me, it crashed on the breakpoint. I didn't know if it was supposed to do that or not, as you can click the attach to gdb button. But when i did that i got no useful info either.

@spotup
Quote:

In which situation it didn't work for you ? It those ones which i describe, or when you do something else ? And what breakpoint, when, where ?:)

Quote:

If attach button present, then by idea you can attach to crashed process, but not in all the cases (for example if crash heavy one, and overwrite important areas of kernel, or anything which can cause problems for gdb itself).

As i understand for you gdb crashes, when you have crash in some programm, then you have GR, press "attach GDB" button, and then GDB crashes ? If so, then what programm is it , have it debug information or not, use it shared objects or not, and can you upload (or point out) on the programm which crash it.

Quote:

What kind of info you want to see in gdb ?:) Even if you will attach gdb to crashed process, then by idea you can only check (by yourself) what happens and where, but i do not know if it good idea to use that "attach gdb button" at all.

Better, its run gdb, and load your crashed programm to it, and then run it (inside of gdb).

To be honest, that "attach gdb" button on the crashed process, can help only to show something which GR already do not show for you (because GR already show registers, disassembly, memory dump, stacktrace). I.e. it mostlu statistic info for you, to know where crash is happens. But as crash _already_ happen, you can't debug it futher, or set breakpoitns, or anything - its already crashed.

So, you then run gdb, and run programm in the GDB, and then, you by youtself (as programmer) think where you need to put breakpoints, what you want to do, where and how execution should stops, so you can understand why it crashes.

Right now, i do not know for what need "attach gdb" button at all. My only "imho" currently its for taking more info than in GR (just for collect information).