Как получить имена функций из заголовков Linux, расположенных в / usr / include - PullRequest
1 голос
/ 20 октября 2010

У нас большинство заголовков библиотеки Gnu C в /usr/include
Я ищу способ открыть и прочитать включаемый файл и проанализировать его, чтобы распечатать все объявленные функции, которые находятся внутри него.
и любой может объяснить или предоставить ссылку, говорящую об этом форматировании заголовков.
Я делаю это потому, что пытаюсь создать плагин для автозаполнения C, который, если я включу файл .h, даст мне все функции, расположенные в файле .h.

Ответы [ 7 ]

8 голосов
/ 20 октября 2010

Каждый в конечном итоге просит такой инструмент, по крайней мере, один раз в своей карьере; что-то, что будет сканировать исходный код C и распечатывать список имен функций / переменных или перекрестную ссылку на вызовы функций между различными модулями.

Чтобы адекватно делать то, что вы просите, вам нужно написать то, что в основном является интерфейсом компилятора C; никакое количество магии регулярных выражений не даст вам того, что вы хотите. Захватите yacc способную версию грамматики языка C и уничтожьте анализатор, используя lex и yacc (или flex и bison, или ваши инструменты по вашему выбору). Однако, когда вы соответствуете объявлению функции, вместо генерации машинных инструкций вы просто распечатаете их (или сохраните в базе данных, или что-то в этом роде).

Запустите интересующий заголовок через существующий препроцессор C (например, gcc -E), чтобы удалить комментарии и выполнить любое расширение макроса, а затем передать полученный файл в свой анализатор.

EDIT

И теперь, когда я действительно прочитал справочную страницу gcc, есть опция -aux-info, которая будет записывать объявления прототипов всех функций, объявленных / определенных в модуле перевода, включая те, которые объявлены во включенных заголовочных файлах. Более того, выходные данные хорошо отформатированы и регулярны, и их должно быть достаточно легко разобрать.

Итак, урок выучен: проверьте документацию вашего компилятора и не обращайте внимания на старые пукающие слова, как я, которые все еще думают с точки зрения инструментов 80-х годов.

2 голосов
/ 20 октября 2010

Doxygen может сделать это.Обычно он запускается на C-источнике, который был аннотирован для его выгоды, но он также может создавать документацию из кода без какой-либо разметки, и вы можете анализировать его вывод XML (или другие форматы) с помощью инструментов по вашему выбору.Захватить анализатор XML с полки и интегрировать его в ваше приложение проще, чем написать синтаксический анализатор C.

Кстати, для вашего плагина автозаполнения C может оказаться неуместным предлагать то, что происходит именно такбыть в файле заголовка в вашей реализации, но которые не определены ни одним из (a) стандарта C, (b) стандарта POSIX, (c) документации расширения GNU.Лично я бы рассматривал стандартные заголовки как особый случай для автозаполнения.У них есть четко определенные интерфейсы, которые перечисляют все функции, которые вы должны ожидать, но они могут также содержать частную нежелательную реализацию.

Этот частный мусор будет иметь зарезервированные имена, так что вы можете пойти дальше, но исключить зарезервированныеимена.

1 голос
/ 21 октября 2010

Заголовки Glibc общеизвестно сложны, имеют много косвенных указаний, поэтому я предполагаю, что они подходят к худшему случаю для чего-то вроде того, что вы пытаетесь сделать.

При этом cscope дает мне разумныйвывод для простого теста с использованием string.h:

$ cscope -bcq /usr/include/string.h
$ cscope -d -L1strcat
/usr/include/string.h strcat 92 extern char *strcat (char *__restrict __dest, __const char *__restrict __src)
/usr/include/bits/string.h strcat 963 #define strcat(dest, src) \
/usr/include/bits/string3.h strcat 164 #define strcat(dest, src) \

Первый вызов cscope предназначен для генерации базы данных cscope, второй - поиск cscope из командной строки для глобальных идентификаторов (да, этот 1 не интуитивно понятен).

0 голосов
/ 20 октября 2010

Как насчет использования фактического компилятора для разбора?Я думаю, что это очень многообещающая разработка:

http://codesynthesis.com/~boris/blog/2010/05/03/parsing-cxx-with-gcc-plugin-part-1/

О, и другой возможностью было бы посмотреть на информацию отладки в объектных файлах.

0 голосов
/ 20 октября 2010

Напишите LEXer и YACCer, который проверяет исходный код разработчика и сопоставляет их с исходным кодом из $ INCLUDE_PATH разработчика.

Файлы в пути включения имеют тот же формат, что и обычные заголовочные файлы.Ключевые слова одинаковы;но вы можете столкнуться с такими словами, как «extern», которые могут не быть обыденными для начинающего программиста.Я предлагаю вам полностью разбираться в ключевых словах и разбираться в их функциональности в разных точках заголовочных файлов.

ps. Для более сложного решения вам придется рассмотреть условные макросы.* Приветствие.

0 голосов
/ 20 октября 2010

Раздел 0p страниц руководства содержит страницы руководства для заголовков POSIX, а также то, что (или, скорее, должно быть ) определено в каждом.

0 голосов
/ 20 октября 2010

Если вы хотите, чтобы определенные стандартные библиотечные модули, Google их вверх. Например:

http://www.cplusplus.com/reference/clibrary/cstring/

Это был первый результат поиска в Google "string.h". Он содержит подробную информацию обо всех функциях, представленных в cstring.

Если вы хотите отследить все функции во всех заголовках во всех подкаталогах / usr / include, я могу дать вам короткий скрипт bash для этого, но я не вижу смысла.

Ура!

Редактировать: или, как прокомментировал Зак, есть стандартное руководство по библиотеке . Хорошая ссылка, Зак!

...