From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12837 invoked by alias); 26 Jan 2002 03:12:39 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 12783 invoked from network); 26 Jan 2002 03:12:35 -0000 Received: from unknown (HELO hotmail.com) (216.33.149.120) by sources.redhat.com with SMTP; 26 Jan 2002 03:12:35 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 25 Jan 2002 19:12:35 -0800 Received: from 65.35.216.143 by lw4fd.law4.hotmail.msn.com with HTTP; Sat, 26 Jan 2002 03:12:35 GMT X-Originating-IP: [65.35.216.143] From: "Salman Khilji" To: shebs@apple.com Cc: gdb@sources.redhat.com Bcc: Subject: Re: Questions for GDB Developers Date: Fri, 25 Jan 2002 19:12:00 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 26 Jan 2002 03:12:35.0897 (UTC) FILETIME=[4D923290:01C1A617] X-SW-Source: 2002-01/txt/msg00306.txt.bz2 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 >To: Salman Khilji >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