emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs contributions, C and Lisp


From: David Kastrup
Subject: Re: Emacs contributions, C and Lisp
Date: Tue, 25 Feb 2014 16:23:49 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

Stephen Leake <address@hidden> writes:

> David Kastrup <address@hidden> 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:

address@hidden:/tmp$ gcc -fdump-xref test.c
cc1: error: unrecognized command line option ‘-fdump-xref’
address@hidden:/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.

address@hidden:/tmp$

-- 
David Kastrup




reply via email to

[Prev in Thread] Current Thread [Next in Thread]