This is the mail archive of the
mailing list for the GDB project.
Questions for GDB Developers
- From: "Salman Khilji" <salmankhilji at hotmail dot com>
- To: gdb at sources dot redhat dot com
- Date: Fri, 25 Jan 2002 12:52:54 +0000
- Subject: Questions for GDB Developers
I am emailing the developers/maintainers of GDB because only they can answer
these questions. I am going to present my questions first and then give a
detailed explanation of what I am trying to do with GDB.
1) Suppose we have to isolate the symbol dictionary code into a separate
library so that this library can potentially be used to create a new
debugger. Which source files do we have to include in this library? I am
talking about the code that reads object/symbol files, determines the
addresses and types of global variables and dynamically allocated memory. I
am not interested in stack variables.
2) I downloaded the source rpm from Mandrake. If I have to build GDB for
different configurations for different platforms like Redhat, Windows
2000/XP, VxWorks, RT Linux, SGI, will I have to get a different source
package for each platform?
3) Is there some documentation besides "GDB Internals" that lists all the
source files along with a one-liner description of what this file is there
for? What are the other sources that I can use to get up to speed on this?
I assume that there would be documentation available for someone that is
going to join the GDB maintenance team. Is there such a thing available?
4) Where in the source-code that deals with peeking/poking into the target
memory? I know that my previous 3 questions were platform
independent---this one is not.
5) I know that you can get to the types of the symbols without running the
target at all by reading the object files. I also know that you can get
address of a global variable by examining the map file generated by the
linker. I was trying to read the STABS debug information and the map file
to get to the address of static member variables of C++ objects. How does
GDB resolve this address?
6) Does GDB depend on the target server in VxWorks. I don't know much about
VxWorks but only know that WindRiver provide something that is called target
WHAT I WANT TO DO WITH GDB SOURCE CODE
I want to develop a real-time monitoring "debugger" for simulations. This
is going to be used on real-time OS and ordinary ones like Windows and
Linux. Normally a debugger has to stop the target program---but we cannot
We already have an application that that does a similar thing but works only
on Windows and WATCOM C compiled targets. The application parses the debug
information contained in the object files and creates a symbol dictionary
that contains the addresses and types of global variables. We created the
symbol dictionary format ourselves. This format is very restrictive and
works only for C and FORTRAN---not for C++. The application was later
ported to VxWorks---in this case we ended up using this GNU compiler so that
we could get to the types---addresses were resolved at run time using the
WindRiver provided API.
The application usually requires a daemon running on the target side to do
memory peeking/poking. A TCP/IP connection is established with the daemon
and a request is sent to read/write to a specific address within the target
simulation. The daemon then does its job as soon as a request is received.
Sometimes we also need to plot the time-history of a variable . We have to
compile our target load with some code to accomplish this. Usually
simulation software has to be cycled at a specific rate---say 10 Hz. This
means that a clock is set up to tick 10 times a second and all the code is
called whenever the clock ticks. The execution of the target load is
usually completed before the next tick arrives. This gives rise to spare
time. If we say that we have 30% spare time this means that our code takes
70% of the time to execute between each clock-tick. Data collection is
performed during spare time to minimize impacts on real-time
characteristics. As soon as the simulation code is executed, the code that
is compiled into the target for data collection is executed to record the
values of some global variables. This data is then sent back to our
monitoring application using a TCP/IP connection. As you can see we do not
care about stack variables since the scope of a stack variable is valid only
at the time where the containing function is executed which is not
applicable to RT systems.
1) I want to rewrite this application using symbol related code from GDB.
This will allow us to work with many GNU compilers and many platforms at
once. Otherwise we will have to come up with the symbol handling code
ourselves which is very messy. Want to remove all the code that is related
to single stepping, breakpoint, command processing, UI, etc etc.
2) I want the addresses of global variables only. Want information on C++
objects including their static variables as well.
3) I am thinking about developing the daemon related code myself to do
peeking and poking since this will be target specific. Any
ideas/suggestions are of course welcome.
4) I downloaded the source code but there is so much of it that I am scared
to touch it. I would really appreciate if anyone can point to source-files
that I need to be concerned with.
5) Lastly if such a thing exists, please point me to it!!!
Thanks for reading all this
Chat with friends online, try MSN Messenger: http://messenger.msn.com