Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: [1]   Вниз
  Печать  
Автор Тема: C++ with CLR: Грабли при отладке unmanaged-кода  (Прочитано 7312 раз)
0 Пользователей и 1 Гость смотрят эту тему.
Вад
Команда клуба

ru
Offline Offline
Пол: Мужской

« : 22-06-2011 12:14 » new

На поддержке одного проекта наткнулся на грабли с отладкой полу-.NET, полу-нативного С++-кода.

Диспозиция: проект - dll с .NET-интерфейсом и "мясом" из нативного кода. В debug-конфигурации включена оптимизация по скорости /O2 (зачем так было сделано - отдельный вопрос, автор утверждает, что как раз этим самым избавлялся от граблей, которые в итоге, напротив, проявляются).

Грабли: memcpy/memset и иже с ними в указанной конфигурации под отладчиком работают чудовищно медленно (мегабайтовый блок памяти копируется десятки секунд, на копировании 100-мегабайтового можно смело идти обедать).

Как выяснилось, в силу включенной поддержки CLR, на весь код неявно распространяется прагма #pragma managed, и нативный код де-факто обслуживается построчно managed-отладчиком. Где-то тут коса и находит на камень: managed-отладчик дуреет при виде memcpy и выдаёт чудовищные тормоза (может, он на копирование каждого байта native-отладчику передаёт управление? или делает какие-то свои проверки, я не знаю, не вдавался).

Если заменить вызовы memset/memcpy на простой цикл с поэлементным заполнением/копированием, то всё работает быстро: то есть, проблема где-то в вызовах библиотечных функций.

Если отключить оптимизацию (/Od), проблема пропадает (хотя я не уверен, что она не станет проявляться при каком-то ещё причудливом сочетании факторов): массивы копируются и заполняются быстро, как и положено.


Таким образом, есть грабли в связке: /D "_DEBUG" + /O2 + /clr + нативный код, связанные с работой managed-отладчика по оптимизированному нативному коду: ужасно медленный вызов функций CRT (глубже пока не исследовал)

Собственно, пока есть одна полу-мера и одна полновесная мера борьбы с этим безобразием.
Полумера заключается в отключении оптимизации (в общем-то, и не нужной в режиме отладки) - при этом unmanaged-код по-прежнему контролируется managed-отладчиком, и остаётся опасение, что вылезут какие-нибудь глюки.
Альтернатива - везде, где необходимо, ставить #pragma managed/unmanaged (что непросто в среднего размера проекте с кучей не очень аккуратного кода - придётся попотеть, чтобы везде всё было, и дальнейшая поддержка таких соглашений тоже потребует усилий).

Есть ли здесь ещё какие-то нюансы? У меня с такими кентаврами опыт работы небольшой, поэтому рад буду, если кто-то поделится опытом по части других возможных граблей (в основном, интересует отладка "кентавра", быстродействие пока на втором плане, хотя тоже может потребоваться).
Записан
Страниц: [1]   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines