From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14809 invoked by alias); 22 Apr 2002 23:42:33 -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 14793 invoked from network); 22 Apr 2002 23:42:27 -0000 Received: from unknown (HELO cygnus.com) (205.180.83.203) by sources.redhat.com with SMTP; 22 Apr 2002 23:42:27 -0000 Received: from redhat.com (romulus.sfbay.redhat.com [172.16.27.251]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id QAA09765; Mon, 22 Apr 2002 16:42:25 -0700 (PDT) Message-ID: <3CC49F1A.DC56EDBE@redhat.com> Date: Mon, 22 Apr 2002 16:42:00 -0000 From: Fernando Nasser Organization: Red Hat Canada X-Accept-Language: en MIME-Version: 1.0 To: Scott Moser CC: gdb@sources.redhat.com Subject: Re: GDB plugin proposal References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-04/txt/msg00372.txt.bz2 Scott Moser wrote: > > - From what I understand (not a lawyer), modules would be required to > be GPLed for a few reasons: > 1. to call 'add_cmd' you need to include gdbcmd.h , which is GPLed Leave the call to add_cmd() inside gdb, in the code that loads a plug-in. So, your plug-in code just provides a description in a standard format and does not have to include the GPL'ed header file. Besides, we may change add_cmd() and plug-ins would stop working, so it is better to define and interface at a higher level of abstraction anyway. > 4. the README from gdb/gdbtk/library/plugins/HOW-TO mentions "As the > plug-ins will be loaded into Insight/GDB for execution, the terms of > the GPL also apply to the plug-in code." I believe the same would > apply for plugins of this nature. I wrote that based on list discussions (among Engineers, mind you -- not lawyers). It is based on the assumption that only general purpose libraries that are part of the standard OS distribution (or a major component) can be binary only. But that is the conservative approach. > - if 'plugin unload' proves difficult (at first glance, it seems maybe), it > could possibly be left out, as loading and unloading doesn't provide much > foreseeable benefit Someone can have created user defined commands, added commands to breakpoints etc. It can be done but will require a major rewrite of CLI code. I also believe it does not add much and doesn't worth the effort. > - Its possible that GDB would eventually want to allow an LGPL like > interface for plugins so that binary only plugins could be created. > We are trying to create a libgdb which would be used to create the interactive debugger as well as be incorporated into other tools. Once this is achieved, the possibility of making the libgdb a LGPL'ed library will have to be discussed. -- Fernando Nasser Red Hat Canada Ltd. E-Mail: fnasser@redhat.com 2323 Yonge Street, Suite #300 Toronto, Ontario M4P 2C9