Назовите дерево для встроенного программного обеспечения [закрытым]

Проблема, я думаю, в том, что нам нужно разобрать perentheses, и все же они не являются бинарным оператором? Должны ли мы взять (2) в качестве одного токена, который оценивается в 2?

Паренсы не должны отображаться в дереве выражений, но они влияют на его форму. Например, дерево для (1 + 2) +3 отличается от 1+ (2 + 3):

    +
   / \
  +   3
 / \
1   2

против

    +
   / \
  1   +
     / \
    2   3

Скобки являются «подсказкой» для синтаксический анализатор (например, per superjoe30, чтобы «рекурсивно спуститься»)

10
задан Ron 11 June 2009 в 00:12
поделиться

8 ответов

Один хороший способ добиться этого - использовать опцию - callgraph для компоновщика ARM (armlink), который часть RVCT ( не бесплатно).

Для более подробной информации - документация по графу вызовов .

Из одного из комментариев я понимаю, что вы ищете решение на основе gcc , а это не так. Но это все равно может быть полезно.

5
ответ дан 3 December 2019 в 19:35
поделиться

Посмотрите StackAnalyzer .

1
ответ дан 3 December 2019 в 19:35
поделиться

Просто мысль. Можно ли запустить его на виртуальной машине (например, Valgrind) и взять образцы стека?

1
ответ дан 3 December 2019 в 19:35
поделиться

Графы вызовов из исходного кода не проблема, как упоминалось выше, ваш компилятор или doxygen могут генерировать эту информацию из исходного кода. Большинство современных компиляторов могут генерировать граф вызовов как часть процесса компиляции.

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

На некоторых процессорах вы можете получить модуль трассировки, чтобы вы могли отслеживать покрытие кода, а что нет, если ваш Процессор должен работать на полной скорости для тестирования, и вы также можете запретить инструментированный код. К сожалению, такие инструменты очень дороги. Посмотрите на Машину времени в Зеленых холмах , если у вас есть деньги. Это упрощает все виды отладки.

4
ответ дан 3 December 2019 в 19:35
поделиться

Из исходного кода вы можете использовать Doxygen ] и GraphViz , даже если вы еще не используете Doxygen для документирования своего кода. Его можно настроить так, чтобы он включал все функции и методы, независимо от того, есть ли у них комментарии к документации. С установленным AT&T Graphviz Doxygen будет включать графики вызовов и вызывающих для большинства функций и методов.

Исходя из объектного кода, у меня нет готового ответа. Я предполагаю, что это будет сильно зависеть от цели, поскольку даже при наличии отладочной информации ему пришлось бы анализировать объектный код, чтобы найти вызовы и других пользователей стека. В худшем случае этот подход, похоже, потребует эффективного моделирования цели.

Во время выполнения на целевом оборудовании ваш выбор будет частично зависеть от того, какая встроенная ОС присутствует, и как она управляет стеками для каждого thread.

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

Даже без предварительного заполнения стопки и последующего обхода ее в поисках следов, прерывание может просто выбрать текущее значение указателя стека (для каждого потока) и сохранить запись о его наибольшей наблюдаемой степени. Это потребовало бы хранилища для копии каждого потока SP, и обработчику прерывания не пришлось бы очень много работать для поддержания информации. Конечно, он должен получить доступ к сохраненным состояниям всех активных потоков.

Я не знаю инструмента, который делает это явно.

Если вы используете µC / OS-II из ] Micrium в качестве вашей ОС, вы можете взглянуть на их продукт µC / Probe. Я сам не использовал его, но он утверждает, что позволяет подключенному компьютеру наблюдать за информацией о программах и состоянии ОС почти в реальном времени. Я не удивлюсь, если при необходимости ее можно будет адаптировать к другой ОСРВ.

Это потребовало бы хранилища для копии каждого потока SP, и обработчику прерывания не пришлось бы очень много работать для поддержания информации. Конечно, он должен получить доступ к сохраненным состояниям всех активных потоков.

Я не знаю инструмента, который делает это явно.

Если вы используете µC / OS-II из ] Micrium в качестве вашей ОС, вы можете взглянуть на их продукт µC / Probe. Я сам не использовал его, но он утверждает, что позволяет подключенному компьютеру наблюдать за информацией о программах и состоянии ОС почти в реальном времени. Я не удивлюсь, если при необходимости ее можно будет адаптировать к другой ОСРВ.

Это потребовало бы хранилища для копии каждого потока SP, и обработчику прерывания не пришлось бы очень много работать для поддержания информации. Конечно, он должен получить доступ к сохраненным состояниям всех активных потоков.

Я не знаю инструмента, который делает это явно.

Если вы используете µC / OS-II из ] Micrium в качестве вашей ОС, вы можете взглянуть на их продукт µC / Probe. Я сам не использовал его, но он утверждает, что позволяет подключенному компьютеру наблюдать за информацией о программах и состоянии ОС почти в реальном времени. Я не удивлюсь, если при необходимости ее можно будет адаптировать к другой ОСРВ.

я не знаю инструмента, который делает это явно.

Если вы используете микроСи / ОС-II из Микриум в качестве своей ОС, вы можете взглянуть на их продукт микроконтроллеров / датчиков. Я сам не использовал его, но он утверждает, что позволяет подключенному компьютеру наблюдать за информацией о программах и состоянии ОС почти в реальном времени. Я не удивлюсь, если при необходимости ее можно будет адаптировать к другой ОСРВ.

я не знаю инструмента, который делает это явно.

Если вы используете микроСи / ОС-II из Микриум в качестве своей ОС, вы можете взглянуть на их продукт микроконтроллеров / датчиков. Я сам не использовал его, но он утверждает, что позволяет подключенному компьютеру наблюдать за информацией о программах и состоянии ОС почти в реальном времени. Я не удивлюсь, если при необходимости ее можно будет адаптировать к другой ОСРВ.

4
ответ дан 3 December 2019 в 19:35
поделиться

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

Это работает довольно хорошо.

Visual Studio будет делать то же самое (но это не бесплатно). Я использую Visual Studio для работы над встроенными проектами; используя проект makefile, я могу выполнять всю работу, кроме отладки, в VS IDE.

1
ответ дан 3 December 2019 в 19:35
поделиться

Я не использовал их, но знаете ли вы:

Поскольку они анализируют исходный код, они не вычисляют глубину стека.

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

Глубина стека и / или создание дерева вызовов может поддерживаться инструментами компилятора. Например, для микросхем Renesas есть утилита под названием Call Walker .

2
ответ дан 3 December 2019 в 19:35
поделиться

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

Я не знаком с этой конкретной целью, но есть доступно все количество доступных эмуляторов ARM с открытым исходным кодом (freshmeat, sourceforge, google), и вас, вероятно, больше всего интересуют коды операций, связанные с вызовом / ответом и push / pop? For example check out skyeye.

So, even if you find that it's not straightforward to extend a compiler or an emulator to provide this information, it should still be possible to create a simple script in order to look for the entrypoint and all calls/rets, as well as opcodes related to stack usage.

Of course, the only reliable information on stack usage is going to come from runtime instrumentation, preferably exercising all important code paths.

1
ответ дан 3 December 2019 в 19:35
поделиться
Другие вопросы по тегам:

Похожие вопросы: