Проблема с файлами карт Delphi x64

Question

Когда я добавляю файлы карт в 64-битном проекте Delphi XE4 (режим отладки). Iv получил несколько символов, таких как "_zn6", "_zn11" и т. Д. В чем причина? В 32-битном проекте все хорошо. Если я выбираю режим релиза, то информация ясна, но очень скудна. Фрагмент файла карты:

 0005:0000B970       System.Rtti.$pdata$_ZN6System8Generics11Collections8TList__1IPNS_7Typinfo9TTypeInfoEE6RemoveES5_
 0005:0000B97C       System.Rtti.$pdata$_ZN6System8Generics11Collections8TList__1IPNS_7Typinfo9TTypeInfoEE10RemoveItemES5_NS_5Types10TDirectionE
 0005:0000B988       System.Rtti.$pdata$_ZN6System8Generics11Collections8TList__1IPNS_7Typinfo9TTypeInfoEE6DeleteEi
 0005:0000B994       System.Rtti.$pdata$_ZN6System8Generics11Collections8TList__1IPNS_7Typinfo9TTypeInfoEE11DeleteRangeEii
 0005:0000B9AC       System.Rtti.$pdata$_ZN6System8Generics11Collections8TList__1IPNS_7Typinfo9TTypeInfoEE7ExtractES5_
 0005:0000B9B8       System.Rtti.$pdata$_ZN6System8Generics11Collections8TList__1IPNS_7Typinfo9TTypeInfoEE11ExtractItemES5_NS_5Types10TDirectionE
 0005:0000B9C4       System.Rtti.$pdata$_ZN6System8Generics11Collections8TList__1IPNS_7Typinfo9TTypeInfoEE8ExchangeEii
 0005:0000B9D0       System.Rtti.$pdata$_ZN6System8Generics11Collections8TList__1IPNS_7Typinfo9TTypeInfoEE4MoveEii
 0005:0000B9DC       System.Rtti.$pdata$_ZN6System8Generics11Collections8TList__1IPNS_7Typinfo9TTypeInfoEE5FirstEv
 0005:0000B9E8       System.Rtti.$pdata$_ZN6System8Generics11Collections8TList__1IPNS_7Typinfo9TTypeInfoEE4LastEv
 0005:0000B9F4       System.Rtti.$pdata$_ZN6System8Generics11Collections8TList__1IPNS_7Typinfo9TTypeInfoEE5ClearEv
 0005:0000BA00       System.Rtti.$pdata$_ZN6System8Generics11Collections8TList__1IPNS_7Typinfo9TTypeInfoEE6ExpandEv
 0005:0000BA0C       System.Rtti.$pdata$_ZN6System8Generics11Collections8TList__1IPNS_7Typinfo9TTypeInfoEE8ContainsES5_
 0005:0000BA18       System.Rtti.$pdata$_ZN6System8Generics11Collections8TList__1IPNS_7Typinfo9TTypeInfoEE7IndexOfES5_
 0005:0000BA24       System.Rtti.$pdata$_ZN6System8Generics11Collections8TList__1IPNS_7Typinfo9TTypeInfoEE11IndexOfItemES5_NS_5Types10TDirectionE
 0005:0000BA30       System.Rtti.$pdata$_ZN6System8Generics11Collections8TList__1IPNS_7Typinfo9TTypeInfoEE11LastIndexOfES5_
 0005:0000BA3C       System.Rtti.$pdata$_ZN6System8Generics11Collections8TList__1IPNS_7Typinfo9TTypeInfoEE7ReverseEv
 0005:0000BA48       System.Rtti.$pdata$_ZN6System8Generics11Collections8TList__1IPNS_7Typinfo9TTypeInfoEE4SortEv
 0005:0000BA54       System.Rtti.$pdata$_ZN6System8Generics11Collections8TList__1IPNS_7Typinfo9TTypeInfoEE4SortENS_15DelphiInterfaceINS0_8Defaults12IComparer__1IS5_EEEE
 0005:0000BA60       System.Rtti.$pdata$_ZN6System8Generics11Collections8TList__1IPNS_7Typinfo9TTypeInfoEE12BinarySearchES5_Ri
 0005:0000BA6C       System.Rtti.$pdata$_ZN6System8Generics11Collections8TList__1IPNS_7Typinfo9TTypeInfoEE12BinarySearchES5_RiNS_15DelphiInterfaceINS0_8Defaults12IComparer__1IS5_EEEE
 0005:0000BA78       System.Rtti.$pdata$_ZN6System8Generics11Collections8TList__1IPNS_7Typinfo9TTypeInfoEE10TrimExcessEv
 0005:0000BA84       System.Rtti.$pdata$_ZN6System8Generics11Collections8TList__1IPNS_7Typinfo9TTypeInfoEE7ToArrayEv
 0005:0000BA90       System.Rtti.$pdata$_ZN6System8Generics11Collections8TList__1IPNS_7Typinfo9TTypeInfoEE13GetEnumeratorEv
 0005:0000BA9C       System.Rtti.$pdata$_ZN6System8Generics11Collections8TList__1IPNS_7Typinfo9TTypeInfoEE11TEnumeratorIE10GetCurrentEv
 0005:0000BAA8       System.Rtti.$pdata$_ZN6System8Generics11Collections8TList__1IPNS_7Typinfo9TTypeInfoEE11TEnumeratorIE12DoGetCurrentEv
 0005:0000BAB4       System.Rtti.$pdata$_ZN6System8Generics11Collections8TList__1IPNS_7Typinfo9TTypeInfoEE11TEnumeratorIE10DoMoveNextEv
 0005:0000BAC0       System.Rtti.$pdata$_ZN6System8Generics11Collections8TList__1IPNS_7Typinfo9TTypeInfoEE11TEnumeratorIEC3EPNS2_IS5_EE
 0005:0000BAD8       System.Rtti.$pdata$_ZN6System8Generics11Collections8TList__1IPNS_7Typinfo9TTypeInfoEE11TEnumeratorIE8MoveNextEv

Вот пример журнала JCL (с файлами карт x64):

ERR (ThreadID=12E0 25.01.2014 23:06:28:098) - External exception E06D7363
Exception class: EExternalException
Exception address: 000007FEFD7DBCCD
Stack list, generated 25.01.2014 23:06:27
[000007FEFD7DBCCD] RaiseException + $3D
[00000000775797A8] RtlRaiseException + $248
[000007FEFD7DBCCD] RaiseException + $3D
[000007FEEC70E92C] _CxxThrowException + $D4
[000007FEECB88383] Unknown function at ?GetTotal@ColumnDesc@TablesManager@ProviderEngine@@QEBA_KXZ + $1BF3
[000007FEECB7EB49] Unknown function at DllCanUnloadNow + $33F69
[000007FEECB7B160] Unknown function at DllCanUnloadNow + $30580
[000007FEECB7CC9D] Unknown function at DllCanUnloadNow + $320BD
[00000000030F115D] ConnPool.GetSKRowset (Line 1220, "ConnPool.pas" + 25) + $27
[00000000030F20B2] ConnPool._ZN8Connpool11TConnection9GetResultEN6System15DelphiInterfaceIN6Winapi6Adoint10_RecordsetEEEN11Definitions9TDCReturnENS1_3SetINS_16TRecordsetOptionELSA_0ELSA_2EEEPNS1_7TObjectEb (Line 1341, "ConnPool.pas" + 27) + $1B
[00000000030EEFFF] ConnPool._ZN8Connpool11TConnection18InternalExecuteCmdEv (Line 974, "ConnPool.pas" + 134) + $0
[00000000030EE56E] ConnPool._ZN8Connpool11TConnection7ExecuteEPNS_12TCmdExecArgsE (Line 801, "ConnPool.pas" + 8) + $0
[00000000031C1B97] SKDS._ZN4Skds13TConfigReader7ExecCmdEiN6System13UnicodeStringES2_RKNS1_10OleVariantEPN8Connpool15TCmdExecOptionsEiNS6_9TTranModeEPS3_SA_i (Line 439, "SKDS.pas" + 65) + $0
[00000000031AD053] Dataservice.DoSimpleCall (Line 3241, "Dataservice.pas" + 8) + $167
[00000000031AD929] Dataservice._ZN11Dataservice12TDataservice10RunCommandEiN6System10WideStringES2_RKNS1_10OleVariantES5_RS3_ (Line 3336, "Dataservice.pas" + 44) + $0
[000007FEFE2216D0] Unknown function at SetErrorInfo + $80
[000007FEFE2224D2] DispCallFunc + $262
[000007FEFE221DE1] Unknown function at SetErrorInfo + $791
[0000000002F18242] System.Win.ComObj._ZN6System3Win6Comobj11TAutoObject6InvokeEiRK5_GUIDitPvS6_S6_S6_ + $82
[000000000073407F] Invoker._ZN7Invoker9TKInvoker6InvokeEv (Line 177, "Invoker.pas" + 30) + $73
[00000000007613A5] WorkerThread._ZN12Workerthread14TKWorkerThread17IntCallFromMemoryEN6System15DelphiInterfaceI7IStreamEEii (Line 426, "WorkerThread.pas" + 16) + $0
[0000000000760728] WorkerThread._ZN12Workerthread14TKWorkerThread10WorkInvokeEN6System15DelphiInterfaceI7IStreamEES4_ (Line 391, "WorkerThread.pas" + 59) + $0
[000000000075EEC1] WorkerThread.ProcessRequest (Line 195, "WorkerThread.pas" + 37) + $50
[000000000075F36E] WorkerThread._ZN12Workerthread14TKWorkerThread11DoSomethingEv (Line 218, "WorkerThread.pas" + 4) + $8
[0000000000737038] PoolableThread._ZN14Poolablethread16TKPoolableThread7ExecuteEv (Line 259, "PoolableThread.pas" + 17) + $E
[000000000052C89B] System.Classes._ZN6System7Classes10ThreadProcEPNS0_7TThreadE + $3B
[000000000040DACB] System._ZN6System13ThreadWrapperEPv + $3B
[000000007735652D] BaseThreadInitThunk + $D
[000000007758C521] RtlUserThreadStart + $21

Answer 1

Эти дополнительные имена связаны с другой моделью обработки исключений в x64. На x86 исключения основаны на стеке. На x64 они основаны на таблицах. Это имеет последствия для того, как обрабатывает компилятор except а также finally блоки.

В частности, компилятор / компоновщик должен иметь возможность выводить таблицу исключений, которая описывает код обработки исключений. Насколько я понимаю, имена, которые вы видите с $pdata$ а также $unwind$ создаются компилятором при обработке except а также finally блоки. Эти имена затем используются компоновщиком для создания таблицы исключений, которая записывается в исполняемый файл вывода. И компилятор генерирует такие невыразимые имена, чтобы они не конфликтовали с настоящими именами функций.

Я предполагаю, что вы видите эти имена в ваших следах стека, потому что код обходчика стека JCL не достаточно умен, чтобы расшифровать эти имена. Например, если вы используете madExcept, вы увидите ожидаемые имена.

В общем, проблема в том, что JCL не хватает функциональности.

---

Между обработкой исключений x86 и x64 существует огромная разница. Например, интересно отметить, что скомпилированный код для finally блок появляется дважды в исполняемом файле x64. Рассмотрим эту короткую программу:

procedure Foo;
begin
end;

procedure Main;
begin
  try
  finally
    Foo;
  end;
end;

begin
  Main;
end.

Компилятор преобразует Main в:

Project1.dpr.8: начало
00000000009A30 55               push rbp
000000000099A31 4883EC30         sub rsp,$30
0000000000409A35 488BEC           mov rbp,rsp
0000000000409A38 48896D28 мов [руб + 28 долл.], Руб
Project1.dpr.9: попробуйте
000000000099A3C 90               nop
Project1.dpr.11: Foo;
0000000000409A3D 90               nop
000000000099A3E E8DDFFFFFF вызов Foo
Project1.dpr.13: конец;
0000000000409A43 488D6530 Леа РШП,[руб + 30 $]
00000000009A47 5D               pop rbp
00000000009A48 C3               ret
00000000009949 498D8000000000 Леа Ракс,[rax+$00000000]
Project1.dpr.11: Foo;
00000000009950 50 push rbp
000000000099A51 4883EC20         sub rsp,$20
0000000000995555 488BEC           mov rbp,rsp
00000000009958 E8C3FFFFFF вызов Foo
000000000099A5D 488D6520         lers rsp,[руб + 20 $]
00000000009A61 5D               pop rbp
00000000009A62 C3               ret

Обратите внимание на два звонка Foo, Первый - нормальное исполнение. То есть, когда нет никаких исключений, и finally блок вводится нормально. Второй звонок Foo имеет дело со случаем, когда исключение активно.

Эта вторая версия блока finally фактически компилируется как отдельная функция. Имеет название Project1.$pdata$_ZN8Project13FooEv согласно моему файлу карты.

0005: 00000A50 Project1. $ Pdata$_ZN8Project13FooEv

Он вызывается из основного обработчика исключений, System._DelphiExceptionHandler, И это действительно отдельная функция, о чем свидетельствует тот факт, что ret, Если я брошу исключение внутри try/finally чтобы запустить этот вариант кода, трассировка стека в IDE выглядит следующим образом:

Project1.Main
System._DelphiExceptionHandler ($ 12FAB0,1244912, $ 12E820, 12E730 $):00000000779F9DAD; ntdll.dll:00000000779E8A4C; ntdll.dll:00000000778E2D3E; C:\Windows\system32\kernel32.dll
System._DelphiExceptionHandler($12FAB0,1244976,$12F5C0,$12EF70):00000000779F9D2D; ntdll.dll:00000000779E91CF; ntdll.dll:0000000077A21248; ntdll.dll:000007FEFDA7940D; C:\Windows\system32\KERNELBASE.dll
System._RaiseAtExcept(???,???)
System._RaiseExcept(???)
Project1.Main

Итак, как вы можете видеть, среда IDE способна достичь того, чего не может код JCL, и имеет смысл обработки исключений на основе таблиц.

Под x86 это выглядит совсем иначе:

Project1.Main
Project1.Project1: 7618336a kernel32.BaseThreadInitThunk + 0x12: 77be9f72 ntdll.RtlInitializeExceptionChain + 0x63: 77be9f45 ntdll.RtlInitializeExceptionChain + 0x36

Итак, все эти невыразимые имена связаны с управлением исключениями на основе таблиц. Поведение вполне ожидаемо.