GP2X How To Write An Exception Handler


slygamer

Active Member
Joined
Sep 19, 2005
Messages
795
Location
Brisbane, Australia
Website
Visit site
There is usually an exception handler that can be written to respond to NULL pointer dereferences, divide by zero, etc. Does anyone know how this would be done on the GP2X?
 
Sweet. Thanks for that.

I've also been trying to find out how to walk the callstack in a GCC-compiled application, but Google keeps throwing me articles on using dbghelp.dll. Is this possible in a GCC-compiled application?
 
Walk the callstack .. ie: debugging?

gdb is the norm, but it'd take some work to talk to a remote app on your gp2x I imagine, though such things have been done before :)

jeff
 
gdb is completely foreign to me. I have no idea how to use it, and I don't know how to get it going on the GP2X. So my plan is to do something similar to what we have in our games at work and dump out the callstack to screen whenever something goes wrong. What we use there is pseudo-callstack walking in that every significant function starts with the a CALLSTACK() macro that essentially adds the function name to a list. At the end of the function, the function name is removed from the list.

There is a -g option to gcc that generates debug information in default format. How do we get access to that debug information?
 
It will probably only take about 15 minutes to get the basics of gdb under your belt. The return on investment is huge.
I know it's often a quicker start to just go with what you know, but gdb (gnu debugger might work better wen searching for a quickstart guide on the inet) is worth it.

(Btw, for a backtrace, use the bt command in gdb)

P.
 
The backtrace() function call seems to do what I want, except backtrace_symbols() does not translate the function addresses to symbol names, even if I compile with -g and link with -rdynamic as the manual says.

Does anyone have gdb for arm? I downloaded gdb source and tried building it, but it won't build with arm-linux-gcc from devkitpro. I don't think I have ever got an application distributed as a source tarball to compile. It's frustrating as all hell.

Edit: I found luteijn's screen_gdb in the files archive. Giving that a try.
 
I tried running gdb with my gpe and it came up with this before showing the usual gdb banner text.

Code:
dlopen failed on 'libthread_db.so.1' - /lib/libthread_db.so.1: undefined symbol:
 ps_pglobal_lookup
GDB will not be able to debug pthreads.

How do I fix that? Is it a problem of a newer version of gdb trying to dynamically link to an older version of pthreads that is on the GP2X?

Your file description on the download page references directories that simply don't exist on the GP2X. Do we have to create every directory from share onwards?

Edit: I create the directories as listed on the download page and copied linux.ti to it (without the .ti), but it made no difference to gdb. I didn't copy screen.ti because I'm not using screen.
 
Yup, I get the same problem on GDB with pthreads, so I simply don't try and debug threads created by my apps, and just debug the main one. If it's fixable though, I'm all ears :)

Must say though that GDB is invaluable - stack and memory dumps at crash time are nice, but being able to see the offending line of code and all variables, and then running the code again with a breakpoint before that line to see exactly what went wrong is far better. It would take an absolute age to incorporate the same level of functionality into your own app.
 
Well, I fixed the crash in my code (or rather, the quite messy GP32 version of Yeti3D). Now I just have to fix the barbage that is drawing all over the screen, but at least it isn't crashing.
 
I tried fixing it a little, e.g. by moving the libpthread I used at compile time to the gp2x and setting the LD_LIBRARY_PATH properly, even ran gdb itself through gdb to see where it was going wrong, and dlopen just didn't see the symbol that supopsedly is there (if you lok with strings, or a proper dumper); I think it's a incompatibility related to the different versions of gcc used, but I don't have the time/resolve to debug it more; like Squidge said, it works well enough and with the proper breakpoints you can dance around the problems. Gdb and screen were just a quick hack (didn't touch any of the code, just compiled it) because I was annoyed they weren't there, and they work for what I want them to do. I thought someone would have build better ones by now, but appears they are fit for purpose for most people.

Suggest you make the directories on the gp2x point to your sd-card (ln -s is your friend).

Also, you probably want screen too, it's just so helpful to be able to swap to a different shell to send signals to your process (not just SIGINT and SIGKILL), or interrupt it with ctrl-C, esp. when not running through gdb. Or to restart the menu after you accidentally exited your shell.

P.
 
Hi,

I'm trying to debug an application using GP2X's gdb and USB-serial cable. I've compiled the applicattion without any optimization and adding -ggdb flag, but when I try to debug it in gdb I can see the sentences that are being process only sentences as the following:

Code:
259     in main.c
(gdb)
[tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
[tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
261     in main.c
(gdb)
[tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
262     in main.c
(gdb)
[tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]

Do you know if I'm doing something wrong?

Thanks a lot :)
 
Error seems to refer to terminal stuff not working properly. Did you install the terminfo files? ( In the 'proper' (i.e. where ncurses looks for them) place and removed .ti ending I put on to make them a different filename than the screen executable?)

P.
 
luteijn posted on Feb 4 2006 at 03:13 PM said:
Error seems to refer to terminal stuff not working properly. Did you install the terminfo files? ( In the 'proper' (i.e. where ncurses looks for them) place and removed .ti ending I put on to make them a different filename than the screen executable?)

P.

Yes, I've copied the two files included in your package in the proper directory. Do I need anything more (maybe ncurses)?

You can see my terminfo directory:
Code:
bash-2.05a# ls -R /usr/local/share/terminfo

/usr/local/share/terminfo:
l  s

/usr/local/share/terminfo/l:
linux

/usr/local/share/terminfo/s:
screen

Thanks for your help :)
 
Last edited by a moderator:
as discussed on irc, for anyone else lurking/searching:

gdb probably works better with a TTY than just redirected in/output, so run gdb from within in screen.

source needs to be findable for gdb to show the lines. --directory=DIR command line switch can be helpful here.

If screen's ctrl-a clashes with minicom's use of ctrl-a, you might have to use the -m command line switch to make it use alt instead.

P.
 
Something else that might be relevant, especially if you don't use screen, is the initial setting of the TERM variable when you connect. It really ought to be set to whatever your serial program is emulating, which probably isn't "linux".

If screen works around this then that's cool, but even screen might benefit from having the variable correctly set.
 
gfoot posted on Feb 5 2006 at 06:54 PM said:
Something else that might be relevant, especially if you don't use screen, is the initial setting of the TERM variable when you connect. It really ought to be set to whatever your serial program is emulating, which probably isn't "linux".


True, you'd probably be best off to get the ansi terminfo files and export TERM=ansi when using hypertrm (and set hyperterm to emualte an ansi terminal).


P.
 
Last edited by a moderator:
Back
Top