Questions for GDB Developers

Questions for GDB Developers

[Salman Khilji]

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 
server.

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 
afford this.

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.

MY WISHES
=========

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

Salman

_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com

Re: Questions for GDB Developers

[Stan Shebs]

Salman Khilji wrote:
> 
> 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.

In general, we haven't been interested in doing this, because the
usual rationale has been to violate GDB's licensing terms by making
proprietary debuggers.  If this is for a new free debugger, then it's
worth talking further.

Stan

Re: Questions for GDB Developers

[Michael Snyder]

Salman Khilji wrote:
> 

> 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.

(gdb) set *(char *) 0x1234 = 1
(gdb) print *(char *) 0x1234

Re: Questions for GDB Developers

[Piet/Pete Delaney]

On Sat, Jan 26, 2002 at 03:12:35AM +0000, Salman Khilji wrote:
> I did a little reading on the licensing and yes it does seem that lifting 
> the code and creating a proprietory "real-time data monitor" would be 
> against the licensing.

Why do you think that? I've been of the impression that you can't take
even part of the code. I don't even know if you can call binutils without
the code having to be copyleft. I recall hearing of other programs having
to remove calls to GNU libraries just to stay out of the copyleft restristions.

I would think it even in the spirit of the GNU license that anything intended
to bolt into gdb, like ddd or a stub should also have to be covered by these
concepts. Isn't the idea to build a free and open software environment?

-piet

Re: Questions for GDB Developers

[Salman Khilji]

I did a little reading on the licensing and yes it does seem that lifting 
the code and creating a proprietory "real-time data monitor" would be 
against the licensing.  However, I do have a few things in my mind and would 
like your opinion on whether it sounds like a good idea:

1)  What I think I could do is lift the symbol handling code and memory 
peeking/poking code and create a "debugger" that does not stop the program 
and allows monitoring of variables in real-time.  The program will only be 
able to read the global variables---no stack variables like a source-line 
debugger.  This part would be released under GPL as open-source.  I will 
implement C and C++.  Others can add whatever they want later on (and of 
course I would like others to help me while I develop this---I don't think I 
can do this on my own!!)

2)  The other GUI parts of the monitoring application including plotting, 
scripting, etc etc would remain proprietory.  Open-source projects like DDD 
could then use the functioality in item 1) to implement real-time monitoring 
features.

This way anyone who wants to create such an application will have the hard 
part already done---that is symbol handling.  This way the core of the 
application will remain open-source and other wil be able to contribute to 
it for future enhancements.

I am sure the real-time community would appreciate this.  So what do you 
think?

Salman


>From: Stan Shebs <shebs@apple.com>
>To: Salman Khilji <salmankhilji@hotmail.com>
>CC: gdb@sources.redhat.com
>Subject: Re: Questions for GDB Developers
>Date: Fri, 25 Jan 2002 14:41:36 -0800
>
>Salman Khilji wrote:
> >
> > 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.
>
>In general, we haven't been interested in doing this, because the
>usual rationale has been to violate GDB's licensing terms by making
>proprietary debuggers.  If this is for a new free debugger, then it's
>worth talking further.
>
>Stan



_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com