URN Logo
UNIX Resources » Linux » China Linux Forum » CPU 与 编译器 » 9 » 有人参与过debugger的开发吗?或者研究过GDB实现的?
announcement 声明: 本页内容为中国Linux论坛的内容镜像,文章的版权以及其他所有的相关权利属于中国Linux论坛和相应文章的作者,如果转载,请注明文章来源及相关版权信息。
Resources
China Linux Forum(finished)
Linux Forum(finished)
FreeBSD China(finished)
linuxforum.net
  业界新闻与评论
  自由软件杂谈
  IT 人生
  Linux软件快递
  翻译作坊
  Linux图书与评论
  GNU Emacs/XEmacs
  Linux 中文环境和中文化
  Linux桌面与办公软件
  Linux 多媒体与娱乐版
  自由之窗Mozilla
  笔记本电脑上的Linux
  Gentoo
  Debian 一族
  网络管理技术
  Linux 安装与入门
  WEB服务器和FTP服务器
  域名服务器和邮件服务器
  Linux防火墙和代理服务器应用
  文件及打印服务器
  技术培训与认证
  Linux内核技术
  Linux 嵌入技术
  Linux设备驱动程序
  Linux 集群技术
  LINUX平台数据库
  系统和网络安全
  CPU 与 编译器
  系统计算研究所专栏
  Linux下的GUI软件开发
  C/C++编程版
  PHP 技 术
  Java&jsp技术
  Shell编程技术
  Perl 编 程
  Python 编 程
  XML/Web Service 技术
  永远的Unix
  FreeBSD世界
   
有人参与过debugger的开发吗?或者研究过GDB实现的?
 
 
 
 
 
 
 
 
 
 
Subject: 有人参与过debugger的开发吗?或者研究过GDB实现的?
Author: nibbling    Posted: 2005-05-19 20:27    Length: 147 byte(s)
[Original] [Print] [Top]
最近要参加一个调试器的开发项目,不知道除了了解dwarf格式外,还应该从哪些方面入手!实在是新手,比较迷茫,希望大家给点帮助!这也是原来想了解GCC的一个原因吧!
[Original] [Print] [Top]
Subject: Re: 有人参与过debugger的开发吗?或者研究过GDB实现的?
Author: tigerwood    Posted: 2005-05-20 17:30    Length: 571 byte(s)
[Original] [Print] [Top]
> 最近要参加一个调试器的开发项目,不知道除了了解dwarf格式外,还应该从哪些方面入手!实在是新手,比较迷茫,希望大家给点帮助!这也是原来想了解GCC的一个原因吧!

你可以先看看《GDB INTERNAL》,大略的过一遍即可,或者用GDB调试调试自己, 既掌握GDB的用法,又能了解GDB工作细节。 应该是一举两得。

对了,能问一些你们项目的细节情况吗, 你们要做的是什么样的东西呢? GDB已经比较成熟,也许别人都已经做过了。 如果是与GDB相关,无论是增强还是移植,我建议你们到GDB的邮件列表中去问一问,也许会有意想不到的收获。 我也在做一些跟GDB相关的工作,欢迎交流的说
[Original] [Print] [Top]
Subject: Re: 有人参与过debugger的开发吗?或者研究过GDB实现的?
Author: nibbling    Posted: 2005-05-20 17:43    Length: 128 byte(s)
[Original] [Print] [Top]
我还没正式开始项目,估计是针对嵌入式芯片,实现或者移植一个调试器,能说说你们在做什么吗?真希望好好和你交流交流!哈哈,先谢谢了。
[Original] [Print] [Top]
Subject: Re: 有人参与过debugger的开发吗?或者研究过GDB实现的?
Author: tigerwood    Posted: 2005-05-20 18:04    Length: 296 byte(s)
[Original] [Print] [Top]
嵌入式我不是很了解,但我看GDB邮件列表上很多人在讨论不同嵌入式平台下GDB的开发,多到上面看看应该有好处。 个人感觉先看GDBSERVER那部分比较好一些:代码少,流程简单,只需要考虑底层的东西,而不用处理上层用户接口以及符号处理。 再说嵌入式平台下面好象很多都只是移植一个GDBSERVER然后搞一个远程调试就差不错。
[Original] [Print] [Top]
Subject: Re: 有人参与过debugger的开发吗?或者研究过GDB实现的?
Author: nibbling    Posted: 2005-05-20 19:28    Length: 92 byte(s)
[Original] [Print] [Top]
估计基本原理都差不多吧,谢谢指点,我先看看gdb internal有不明白的还要请教你了!!哈哈,先预约一下!
[Original] [Print] [Top]
Subject: Re: 有人参与过debugger的开发吗?或者研究过GDB实现的?
Author: qiyoa    Posted: 2005-05-21 22:29    Length: 163 byte(s)
[Original] [Print] [Top]
《gdb internals》我看了,但是对gdb的结构还不是很清楚,而且源代码文件很多,很乱。

如果我想在gdb中添加一些命令,有这方面的文档或手册吗?
[Original] [Print] [Top]
Subject: Re: 有人参与过debugger的开发吗?或者研究过GDB实现的?
Author: teawater    Posted: 2005-05-22 12:19    Length: 134 byte(s)
[Original] [Print] [Top]
gdb代码算是比较清晰的了 不如直接看他的代码
gdb中添加一些命令 你可以看看其中对add_cmd以及其中其他几个函数的使用 应该对你有帮助
----
读了这么多年的书 还是觉得幼儿园好混
[Original] [Print] [Top]
Subject: Re: 有人参与过debugger的开发吗?或者研究过GDB实现的?
Author: qiyoa    Posted: 2005-05-22 13:34    Length: 421 byte(s)
[Original] [Print] [Top]
谢谢您的回复,我现在正在看gdb的源代码。

我现在不想让gdb支持那么多的文件格式,只想保留对elf文件和dwarf2调试信息格式的支持,所以在编译的时候只想编译有关的文件,但是我以前做的都是修改Makefile.am,然后automake,autoconf,但是在gdb的源代码中么有Makefile.am这个文件,只有Makefile.in,是直接修改这个文件吗,然后用什么命令生成Makefile啊?

automake,autoconf一直不是很明白,所以在这里请教大家了
[Original] [Print] [Top]
Subject: Re: 有人参与过debugger的开发吗?或者研究过GDB实现的?
Author: teawater    Posted: 2005-05-22 15:04    Length: 318 byte(s)
[Original] [Print] [Top]
“我现在不想让gdb支持那么多的文件格式,只想保留对elf文件和dwarf2调试信息格式的支持,所以在编译的时候只想编译有关的文件”
这个我觉得主要跟bfd有关 你看看bfd那个目录。。。

am这个问题我也遇见过。。。好像很少有在源码包中带am 每次想起来都觉得很奇怪 不带am别人作代码扩展都很不方便 不道谁有什么见解
----
读了这么多年的书 还是觉得幼儿园好混
[Original] [Print] [Top]
Subject: Re: 有人参与过debugger的开发吗?或者研究过GDB实现的?
Author: simtiger    Posted: 2005-05-31 23:03    Length: 81 byte(s)
[Original] [Print] [Top]
对文件格式的支持也是通过bfd来搞定的
GDB也是利用BFD来搞定不同类型的文件的
----
行到水穷处,坐看云起时
[Original] [Print] [Top]
« Previous thread
mips vs arm
CPU 与 编译器
9
Next thread »
请问 Porting GNU ld 从什么地方入手?
     

Copyright © 2007 UNIX Resources Network, All Rights Reserved.      About URN | Privacy & Legal | Help | Contact us
备案序号: 京ICP备05006143    webmaster: webmaster@unixresources.net
This page created on 2008-07-17 03:47:29, cost 0.058922052383423 ms.