Как вы сопоставляете указатель инструкции native на IL-код в процессе
При использовании неуправляемого API для .NET Framework для профилирования внутрипроцессного процесса .NET можно ли искать указатель инструкций IL, который соответствует собственному указателю инструкций, предоставленному функции StackSnapshotCallback?
Как очевидно, я делаю снимок текущего стека и хотел бы предоставить информацию о файле и номере строки в дампе стека. Managed Stack Explorer делает это путем запроса ISymUnmanagedMethod::GetSequencePoints
. Это замечательно, но точки последовательности связаны со смещениями, и я до сих пор предполагал, что это смещения с начала метода (на промежуточном языке).
В последующем комментарии к своему сообщению в блоге " ICorDebugCode::GetILToNativeMapping
: основы и не только" Дэвид Броман указывает, что такое сопоставление может быть достигнуто с помощью ICorDebugCode::GetILToNativeMapping
. Однако это не идеально, так как для получения этого интерфейса требуется присоединение к моему процессу другого процесса отладчика.
Я хотел бы избежать этого шага, потому что я хотел бы продолжать иметь возможность запускать свое приложение из отладчика Visual Studio, пока я делаю эти снимки. Это облегчает нажатие на номер строки в окне вывода и переход к соответствующему коду.
Функциональность возможна.... вы можете выплюнуть трассировку стека с нумерацией строк по желанию внутри управляемого кода, единственный вопрос, доступен ли он. Кроме того, я не хочу использовать функциональность System::Diagnostics::StackTrace
или System::Environment::StackTrace
потому что по соображениям производительности мне нужно отложить фактический дамп стека.... таким образом, сохраняя стоимость для разрешения имен методов и местоположения кода на будущее желательно... наряду с возможностью смешивать собственные и управляемые кадры.
Ответы
Ответ 1
Чтобы перевести с помощью указателя на native-указателя, предоставленного ICorProfilerInfo2::DoStackSnapshot
на смещение промежуточного языка, вы должны выполнить два шага, поскольку DoStackSnapshot
предоставляет указатель FunctionID
и native инструкции в качестве адреса виртуальной памяти.
Шаг 1, заключается в преобразовании указателя инструкции в смещение метода нативного кода. (смещение от начала метода JITed). Это можно сделать с помощью ICorProfilerInfo2::GetCodeInfo2
ULONG32 pcIL(0xffffffff);
HRESULT hr(E_FAIL);
COR_PRF_CODE_INFO* codeInfo(NULL);
COR_DEBUG_IL_TO_NATIVE_MAP* map(NULL);
ULONG32 cItem(0);
UINT_PTR nativePCOffset(0xffffffff);
if (SUCCEEDED(hr = pInfo->GetCodeInfo2(functioId, 0, &cItem, NULL)) &&
(NULL != (codeInfo = new COR_PRF_CODE_INFO[cItem])))
{
if (SUCCEEDED(hr = pInfo->GetCodeInfo2(functionId, cItem, &cItem, codeInfo)))
{
COR_PRF_CODE_INFO *pCur(codeInfo), *pEnd(codeInfo + cItem);
nativePCOffset = 0;
for (; pCur < pEnd; pCur++)
{
// 'ip' is the UINT_PTR passed to the StackSnapshotCallback as named in
// the docs I am looking at
if ((ip >= pCur->startAddress) && (ip < (pCur->startAddress + pCur->size)))
{
nativePCOffset += (instructionPtr - pCur->startAddress);
break;
}
else
{
nativePCOffset += pCur->size;
}
}
}
delete[] codeInfo; codeInfo = NULL;
}
Шаг 2. Когда у вас есть смещение от начала кода кода natvie, вы можете использовать его для преобразования в смещение от начала метода промежуточного языка с помощью ICorProfilerInfo2::GetILToNativeMapping
.
if ((nativePCOffset != -1) &&
SUCCEEDED(hr = pInfo->GetILToNativeMapping(functionId, 0, &cItem, NULL)) &&
(NULL != (map = new COR_DEBUG_IL_TO_NATIVE_MAP[cItem])))
{
if (SUCCEEDED(pInfo->GetILToNativeMapping(functionId, cItem, &cItem, map)))
{
COR_DEBUG_IL_TO_NATIVE_MAP* mapCurrent = map + (cItem - 1);
for (;mapCurrent >= map; mapCurrent--)
{
if ((mapCurrent->nativeStartOffset <= nativePCOffset) &&
(mapCurrent->nativeEndOffset > nativePCOffset))
{
pcIL = mapCurrent->ilOffset;
break;
}
}
}
delete[] map; map = NULL;
}
Затем это можно использовать для сопоставления местоположения кода с файлом и номером строки с помощью API-интерфейсов символов
Благодаря Mithun Shanbhag для направления в поиске решения.
Ответ 2
Console.WriteLine("StackTrace: '{0}'", Environment.StackTrace);
Убедитесь, что ваша сборка генерирует символы.
Расширение обсуждения:
Как очевидно, я делаю снимок текущего стека и хотел бы предоставить информацию о количестве файлов и строк в дампе стека.
Учитывая это - похоже, единственная причина, по которой вы не привязываетесь к процессу, - это то, что вы можете легко отлаживать свой инструмент или его части, когда вы его разрабатываете. Эта ИМО является плохим предлогом для того, чтобы не выбирать лучший дизайн (ICorDebug или w/e), когда он доступен. Причина его плохого дизайна заключается в том, что ваш код выполняется в пространстве процессов (предположительно) внешних двоичных файлов, вызывая неприятные (иногда "редкие" ) побочные эффекты (в том числе развращение чужих данных) в известных (или хуже - неизвестных) состояниях коррумпированного процесса. Этого должно быть достаточно для начала, но даже в противном случае существует несколько краевых случаев с многопоточным кодом и т.д., Где дизайн должен быть обработан.
Большинство людей обычно спрашивают: "Что вы действительно пытаетесь сделать?" как ответ на откровенно сложный способ делать вещи. В большинстве случаев есть более простой/более простой способ. Написав трассировщик стека для собственного кода, я знаю, что он может запутаться.
Теперь, может быть, вы могли бы заставить все работать, так что - Только мои $.02