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 上，它们是 table based。这会对编译器如何处理 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：开始 0000000000409A30 55 推 rbp 0000000000409A31 4883EC30 sub rsp,$30 0000000000409A35 488BEC mov rbp,rsp 0000000000409A38 48896D28 mov [rbp+$28],rbp Project1.dpr.9：试试 0000000000409A3C 90 无 Project1.dpr.11：Foo； 0000000000409A3D 90 无 0000000000409A3E E8DDFFFFFF 呼叫 Foo Project1.dpr.13：结束； 0000000000409A43 488D6530 lea rsp,[rbp+$30] 0000000000409A47 5D 流行 rbp 0000000000409A48 C3 RET 0000000000409A49 488D8000000000 lea rax,[rax+$00000000] Project1.dpr.11：Foo； 0000000000409A50 55 推 rbp 0000000000409A51 4883EC20 sub rsp,$20 0000000000409A55 488BEC mov rbp,rsp 0000000000409A58 E8C3FFFFFF 呼叫 Foo 0000000000409A5D 488D6520 lea rsp,[rbp+$20] 0000000000409A61 5D pop rbp 0000000000409A62 C3 RET

注意对Foo 的两次调用。第一个是正常执行。也就是没有异常的情况下，finally块是正常进入的。第二次调用Foo 处理异常活动的情况。

finally 块的第二个版本实际上被编译为一个单独的函数。根据我的地图文件，它的名称为Project1.$pdata$_ZN8Project13FooEv。

0005:00000A50 项目 1.$pdata$_ZN8Project13FooEv

它是从主异常处理程序System._DelphiExceptionHandler 调用的。它确实是一个单独的函数，从它以ret 结尾的事实可以看出。如果我在 try/finally 中抛出异常以运行此代码变体，IDE 中的堆栈跟踪如下所示：

项目1.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._RaiseAtException(???,???) System._RaiseException(???) 项目1.Main

如您所见，IDE 能够实现 JCL 代码无法实现的功能，并且能够理解基于表的异常处理。

在 x86 下看起来完全不同：

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

所以，这些难言的名字都与基于表的异常的管理有关。这种行为完全在意料之中。