From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Emacs contributions, C and Lisp Date: Tue, 25 Feb 2014 16:23:49 +0100 Organization: Organization?!? Message-ID: <878usz8bcq.fsf@fencepost.gnu.org> References: <831tz5daes.fsf@gnu.org> <8738jlohd6.fsf@yandex.ru> <83txc1bl83.fsf@gnu.org> <5300189A.9090208@yandex.ru> <83wqgv9fbj.fsf@gnu.org> <20140216180712.236069f6@forcix.jorgenschaefer.de> <87wqgr4v18.fsf@yandex.ru> <53064BD0.7070009@yandex.ru> <87ha7tr5bo.fsf@fencepost.gnu.org> <87ppmhecd8.fsf@yandex.ru> <87y50z90pd.fsf@fencepost.gnu.org> <87txbn8r6x.fsf@fencepost.gnu.org> <85wqgj45pq.fsf@stephe-leake.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1393341857 12370 80.91.229.3 (25 Feb 2014 15:24:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 25 Feb 2014 15:24:17 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 25 16:24:26 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WIJrs-00079g-Tp for ged-emacs-devel@m.gmane.org; Tue, 25 Feb 2014 16:24:25 +0100 Original-Received: from localhost ([::1]:35487 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIJrs-0001Q2-HD for ged-emacs-devel@m.gmane.org; Tue, 25 Feb 2014 10:24:24 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48017) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIJrl-0001Ps-Vi for emacs-devel@gnu.org; Tue, 25 Feb 2014 10:24:22 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WIJrh-0006FV-AA for emacs-devel@gnu.org; Tue, 25 Feb 2014 10:24:17 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:42709) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIJrg-0006CW-Vt for emacs-devel@gnu.org; Tue, 25 Feb 2014 10:24:13 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1WIJrb-0005zy-P1 for emacs-devel@gnu.org; Tue, 25 Feb 2014 16:24:07 +0100 Original-Received: from x2f51cea.dyn.telefonica.de ([2.245.28.234]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 25 Feb 2014 16:24:07 +0100 Original-Received: from dak by x2f51cea.dyn.telefonica.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 25 Feb 2014 16:24:07 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 54 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: x2f51cea.dyn.telefonica.de X-Face: 2FEFf>]>q>2iw=B6, xrUubRI>pR&Ml9=ao@P@i)L:\urd*t9M~y1^:+Y]'C0~{mAl`oQuAl \!3KEIp?*w`|bL5qr,H)LFO6Q=qx~iH4DN; i"; /yuIsqbLLCh/!U#X[S~(5eZ41to5f%E@'ELIi$t^ Vc\LWP@J5p^rst0+('>Er0=^1{]M9!p?&:\z]|;&=NP3AhB!B_bi^]Pfkw User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) Cancel-Lock: sha1:m/X0E9Bz8H86sOj9lyMSw4TgbhI= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:169860 Archived-At: Stephen Leake writes: > David Kastrup writes: > >> In this particular case, the "annotated syntax tree" question in >> particular is mostly uninteresting since we are talking about >> characterizing identifiers. It is "mostly" uninteresting since the >> resolution of an identifier depends on scopes, so the basic question >> that likely needs solving is "given the following source location and >> the following identifier, what data structures and definitions does it >> refer to". Resolving identifiers based on source location efficiently >> will require suitable data structures, and any daemon answering >> questions accordingly will have to get raw data for building them. >> >> Accessing that raw data and preparing a dump suitable for turning into a >> data structure for such a daemon would seem like an obvious case for a >> GCC plugin. So we are getting more at something like "source location >> dependent data structure dump" here. > > That is what 'gcc -fdump-xref' does now. Can't find it in the GCC 4.8 docs. > AdaCore provides a tool 'gnatinspect' that reads that data and answers > queries about it: http://libre.adacore.com/, gnatcoll package. > > Emacs Ada mode 5.0.1 (in Gnu ELPA) has experimental code to start > gnatinspect in a process and feed it queries, for Ada, C, C++. Well, as I explicated previously, I consider it a good idea that any semi-persistent program would be a different executable from the original GCC process in order not to have all the parsing memory garbage staying around indefinitely. gcc -fdump-xref would likely use an external file rather than a pipe but I think the preprocessing stages likely use external files anyway so avoiding temporary disk usage in the setup space is not likely feasible anyway. Other than that, this seems like it would likely fit the bill. Pity that does not seem to be in GCC 4.8: dak@lola:/tmp$ gcc -fdump-xref test.c cc1: error: unrecognized command line option ‘-fdump-xref’ dak@lola:/tmp$ gcc --version gcc (Ubuntu/Linaro 4.8.1-10ubuntu9) 4.8.1 Copyright (C) 2013 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. dak@lola:/tmp$ -- David Kastrup