From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1846 invoked by alias); 1 May 2013 04:31:57 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 1835 invoked by uid 89); 1 May 2013 04:31:57 -0000 X-Spam-SWARE-Status: No, score=-5.1 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.1 Received: from mail-ve0-f176.google.com (HELO mail-ve0-f176.google.com) (209.85.128.176) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Wed, 01 May 2013 04:31:56 +0000 Received: by mail-ve0-f176.google.com with SMTP id cz11so984840veb.21 for ; Tue, 30 Apr 2013 21:31:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=5NxQHMqfjojD8ii+FrVniyVQuX4m/XtvVyIJROHBDc0=; b=hhWmWCSaAIo/1J2aRiKY9ymLXOLjDWVcrKb8GeQiBTV3wTPnMToZVNUIHW6m2Mnsi1 LkxKP9DsgyMq0+yM5ieH6kAd/94S/WF132T/KaedQtnXIRKntzy7Vljpi0Opeu5hrnFb BWRLF8FU63Kft70M2NIW5ebDUlHJBu2sfHDqoaAxvXuPbeX0lJ33+sFsvzpgw0NUFK8y chvmpjxjaow2RvPlgR927GgA8jm2PwQRyUiUtr8uMuarjMeTzRG9cvu7H9pCSTiEV/P4 DyH9FAO4mvW0l58QKWqu9Ydn7NT+/Rh649r4oE+HYu9e+eMbfDN8iqOqINYD8QQ3qcuB mu7g== MIME-Version: 1.0 X-Received: by 10.220.189.9 with SMTP id dc9mr444648vcb.8.1367382713933; Tue, 30 Apr 2013 21:31:53 -0700 (PDT) Received: by 10.220.173.7 with HTTP; Tue, 30 Apr 2013 21:31:53 -0700 (PDT) In-Reply-To: <1367380182.25105.105.camel@Renee-desktop.suse> References: <1367308142.25105.25.camel@Renee-desktop.suse> <1367380182.25105.105.camel@Renee-desktop.suse> Date: Wed, 01 May 2013 04:31:00 -0000 Message-ID: Subject: Re: About adding new script language From: Doug Evans To: Nala Ginrut Cc: "gdb@sourceware.org" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlKSCjdwnoyneNMxffOYDuwQ5pCKzaF6npZddVgp5k2RJXpYMMoZZm1mVvKwBWHNBrKx+/vj3ubRT2QMs05dLJmWqcpvBaeRJawKCiPa20HVlLkp9+DnNLooUyDEfURcvXK11bIdUUZlwuPzzcWOJJDm1KinMkkfoZk20RYFHb+OzsCF64FTNKI2EMHDcyKrENzzLDe X-SW-Source: 2013-05/txt/msg00003.txt.bz2 On Tue, Apr 30, 2013 at 8:49 PM, Nala Ginrut wrote: > hi Doug! Thanks for reply! > > On Tue, 2013-04-30 at 17:51 -0700, Doug Evans wrote: >> There aren't any interfaces, they need to be added. >> One of the hardest parts of adding Guile support to GDB (as an >> extension language) >> will be providing reasonable interfaces. >> > > Could you give me some hints where is the preferable place to cut in? Not at this time. If it were me, I'd study the gdb/python directory, and all the places in gdb/*.c that call into gdb/python/*.c. [There may be other places in cli/*.c and mi/*.c, I don't know off hand and it's trivial to check.] > Here're my questions: > 1. Find a way to get the input string and pass it to guile for eval when > 'Guile mode' enabled. I know python module has some functions to handle > this, but I don't know how the things from GDB passed in. Maybe some > hooks in GDB REPL? For a first pass, I would not invent anything new. [If you want to try to invent sometthing, I"m not saying don't try, but I think you'll get better traction, and get up to speed quicker, by not trying to invent anything, and start by just providing in gdb+Guile what is already provided in gdb+Python.] GDB provides the "python-interactive" command to invoke the Python REPL. Thus if you want a Guile REPL from GDB, write a guile-interactive (scheme-interactive?) command that starts a Guile REPL. Also, GDB also provides Python access to gdb's stdout,etc (see gdb/python/python.c). And there is gdb/python/py-gdb-readline.c to provide Python access to GDB's readline. > 2. When in 'Guile mode', there should be a way to get the context info > of gdb. I know python could do it with gdb module, like 'gdb.a' to get > the variable named 'a'. My question is how to interact with GDB context? > Any docs for that? There is the gdb module in Python, but "gdb.a" is not used to get the variable named "a". One way would be gdb.parse_and_eval("a"). There are no such internal docs that I'm aware of. If it were me, I'd just look at the code anyway. OTOH, there are lots of docs for the Python API from the user's perspective. E.g., bash$ info -f gdb -n Python > 3. According to our previous discussion, there's no need to write a > general interfaces for extension language (maybe not?). So I think the > easier way is to find out what's in GDB is most useful thing, and write > the wrapper for Guile. Any suggestion? Depends I think. I think(!) we definitely do not want the following littered throughout gdb (for example): #ifdef HAVE_PYTHON if (using_python) python_api_func_1 (); #endif #ifdef HAVE_GUILE if (using_guile) guile_api_func_1 (); #endif Not because I'm thinking we might someday want to add another language, but simply because even with only two languages it's too clumsy. > 4. If we do need to add the clean interfaces, what part of code should I > take a look? I'm not sure in the general case. I can think of a way to go that would work for me, but no one has really looked at supporting multiple scripting languages. The canonical solution would be a struct with some state and a set of function pointers defining the API, with the Python implementation in gdb/python/*.c and the Guile implementation in gdb/guile/*.c. [More would be needed on top of that, but that's a start.]