XRP Ninja

I just found that, it is actually very easy to trigger the problem that the -mfix-ls2f-kernel as option could fix. Like just emerging glibc could hang the system. So if you are using linux-loongson/2.6.30/stable branch from this git tree http://dev.lemote.com/git?p=rt4ls.git;a=summary, you maybe want to line 129 of arch/mips/Makefile: $(call cc-option,-march=loongson2f,-march=r4600) $(call cc-optoin,-mtune=loongson2f) to $(call cc-option,-march=loongson2f,-march=r4600) $(call as-option,-Wa$(comma)-mfix-ls2f-kernel,) Actually, $(call cc-optoin,-mtune=loongson2f) here is not required. BTW, glibc-2.10.1 is ready in my overlay. This version could solve the gdb issue: Error while reading shared library symbols: find_new_threads_callback: cannot get thread info: generic error find_new_threads_callback: cannot get thread info: generic error This happened previously when debugging multithread applications.

使用GDB/Emacs debug C++程序 Date: 2006-09-26 Version: 1.0 Authors: 张乐 内容 gdb使用技巧 注意事项 准备工作 运行 设置断点 检查状态 继续运行 信号 与Emacs配合使用 gdb使用技巧 注意事项 gdb使用 Readline 库 可以使用bash快捷键，tab补齐 清除inputrc里有冲突的设置 准备工作 重新编译安装程序。系统里现有的程序一般不适合直接拿来跟踪。需要使用合理的CFLAGS重新编译安装后再跟踪。 ./configure find -name "Makefile" | xargs sed -i -e 's/^CFLAGS = /CFLAGS = -g3 -ggdb3 -gdwarf-2 /' make && make install 运行 启动gdb a. gdb bayonne b. gdb --args bayonne -vvv script.scr 利用帮助 a. help 命令类别名 b. help 命令名 运行程序 a. r[un] b. r[un] -vvv script.scr 设置断点 按照函数名设置断点 b[reak] main b[reak] 'namespace::Class::func()' 按照文件名和行数设置断点 b[reak] methods.cpp:523 检查状态 检查堆栈 b[ack]t[race] up down 检查当前函数的源代码 list 检查/改变变量值 p[rint] var p[rint] ptr->mem p[rint] *ptr p[rint] ('namespace::Class') *this p[rint] (('namespace::Class') *this)->a.b.c p[rint] var=value 检查类 ptype ptr set print object on whatis ptr 检查并启用/禁用断点 set breakpoint pending on info b[rea