SLDP: Usage of PE library context by debugger?


Marvin Häuser
 

Good day everyone,

While refining the port of SourceLevelDebugPkg to my newly proposed PeCoffLib rework (RFC upcoming), I noticed that the address of the PE Image context is written to DR2 [1]. Because the UDK and Intel System Studio debugging tools are closed source, I cannot verify what happens to this value. Does the host read the library context and retrieve data from it? If not, why is its address written to DR2? If so, this would mean the new PeCoffLib implementation breaks the existing debugging tools. The following questions would arise:

1) Which data are retrieved from the context structure? For GDB, I think only the Image address and symbol file path are required (to load the symbols), while PDB is saved in DR1 already.
2) Are there any plans to provide detailed documentation of the host/client communication protocol?
3) Are there any plans to provide an open source debugger, or at least the EDK II communication protocol portion?

Thank you for your time!

Best regards,
Marvin


[1] https://github.com/tianocore/edk2/blob/610bcc69ed3d1e8c016332a1862465d41d95dd6c/SourceLevelDebugPkg/Library/PeCoffExtraActionLibDebug/PeCoffExtraActionLib.c#L126


Ni, Ray
 

Marvin,
Host assumes first 8-byte (little endian) of memory pointed by DR2 is the value of Image base address.
DR1 points to the PDB path (I am sure you noticed that in the SourceLevelDebugPkg code).

There is no plan to provide detailed documentation of host/client communication protocol. So far, the brief explanation can be seen in SourceLevelDebugPkg\Include\TransferProtocol.h.

I admit that if the old me had the mindset of today's me, a detailed markdown doc should have been provided in SourceLevelDebugPkg.
I will check internally on the open source plan, but please don't heavily rely on that.

Thanks,
Ray

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Marvin H?user
Sent: Sunday, August 1, 2021 1:21 AM
To: devel@edk2.groups.io
Cc: Wu, Hao A <hao.a.wu@intel.com>
Subject: [edk2-devel] SLDP: Usage of PE library context by debugger?

Good day everyone,

While refining the port of SourceLevelDebugPkg to my newly proposed PeCoffLib rework (RFC upcoming), I noticed that the address of the PE Image context is written to DR2 [1]. Because the UDK and Intel System Studio debugging tools are closed source, I cannot verify what happens to this value. Does the host read the library context and retrieve data from it? If not, why is its address written to DR2? If so, this would mean the new PeCoffLib implementation breaks the existing debugging tools. The following questions would arise:

1) Which data are retrieved from the context structure? For GDB, I think only the Image address and symbol file path are required (to load the symbols), while PDB is saved in DR1 already.
2) Are there any plans to provide detailed documentation of the host/client communication protocol?
3) Are there any plans to provide an open source debugger, or at least the EDK II communication protocol portion?

Thank you for your time!

Best regards,
Marvin


[1]
https://github.com/tianocore/edk2/blob/610bcc69ed3d1e8c016332a1862465d41d95dd6c/SourceLevelDebugPkg/Library/PeCoffExtraActionLibDebug/PeCoffExtraActionLib.c#L126


Jeff Fan
 

Marvin,

ImageBase was saved in DR2 to help HOST debugger to locate the image base more easily, even though the HOST debugger could find the image base through searching the DOS image signagure.

The reason choosing DR1 and DR2 to save PDB & ImageBase contexts is just implementation only. And it could co-work with Debug Agent Lib implementation and SIMCS.  I am not sure whether is could co-work with INTEl System Debugging tools or not.

I don't understand why the new PeCoffLib implementation would break the existing debugging tools?Could you explain it more details?


Jeff
fanjianfeng@...

 
Date: 2021-08-01 01:21
Subject: [edk2-devel] SLDP: Usage of PE library context by debugger?
Good day everyone,
 
While refining the port of SourceLevelDebugPkg to my newly proposed
PeCoffLib rework (RFC upcoming), I noticed that the address of the PE
Image context is written to DR2 [1]. Because the UDK and Intel System
Studio debugging tools are closed source, I cannot verify what happens
to this value. Does the host read the library context and retrieve data
from it? If not, why is its address written to DR2? If so, this would
mean the new PeCoffLib implementation breaks the existing debugging
tools. The following questions would arise:
 
1) Which data are retrieved from the context structure? For GDB, I think
only the Image address and symbol file path are required (to load the
symbols), while PDB is saved in DR1 already.
2) Are there any plans to provide detailed documentation of the
host/client communication protocol?
3) Are there any plans to provide an open source debugger, or at least
the EDK II communication protocol portion?
 
Thank you for your time!
 
Best regards,
Marvin
 
 
[1]
https://github.com/tianocore/edk2/blob/610bcc69ed3d1e8c016332a1862465d41d95dd6c/SourceLevelDebugPkg/Library/PeCoffExtraActionLibDebug/PeCoffExtraActionLib.c#L126
 
 
 
 
 


Marvin Häuser
 

02.08.2021 05:09:29 Ni, Ray <ray.ni@intel.com>:

Marvin,
Host assumes first 8-byte (little endian) of memory pointed by DR2 is the value of Image base address.
Thanks Ray! So I can be confident no further data from the context are or will be queried and I can just publish the Image base from the stack for example?

Maybe another thing, is the Image base address used for anything but loading the symbols (analogous to GCC "add-symbol-file")? E.g. does it ever try to read and parse the Image header? Mostly I am interested in how changes to the TE format would affect the tool.

Best regards,
Marvin

DR1 points to the PDB path (I am sure you noticed that in the SourceLevelDebugPkg code).

There is no plan to provide detailed documentation of host/client communication protocol. So far, the brief explanation can be seen in SourceLevelDebugPkg\Include\TransferProtocol.h.

I admit that if the old me had the mindset of today's me, a detailed markdown doc should have been provided in SourceLevelDebugPkg.
I will check internally on the open source plan, but please don't heavily rely on that.
Thanks!


Thanks,
Ray

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Marvin H?user
Sent: Sunday, August 1, 2021 1:21 AM
To: devel@edk2.groups.io
Cc: Wu, Hao A <hao.a.wu@intel.com>
Subject: [edk2-devel] SLDP: Usage of PE library context by debugger?

Good day everyone,

While refining the port of SourceLevelDebugPkg to my newly proposed PeCoffLib rework (RFC upcoming), I noticed that the address of the PE Image context is written to DR2 [1]. Because the UDK and Intel System Studio debugging tools are closed source, I cannot verify what happens to this value. Does the host read the library context and retrieve data from it? If not, why is its address written to DR2? If so, this would mean the new PeCoffLib implementation breaks the existing debugging tools. The following questions would arise:

1) Which data are retrieved from the context structure? For GDB, I think only the Image address and symbol file path are required (to load the symbols), while PDB is saved in DR1 already.
2) Are there any plans to provide detailed documentation of the host/client communication protocol?
3) Are there any plans to provide an open source debugger, or at least the EDK II communication protocol portion?

Thank you for your time!

Best regards,
Marvin


[1]
https://github.com/tianocore/edk2/blob/610bcc69ed3d1e8c016332a1862465d41d95dd6c/SourceLevelDebugPkg/Library/PeCoffExtraActionLibDebug/PeCoffExtraActionLib.c#L126



Marvin Häuser
 

02.08.2021 06:51:39 Jeff Fan <fanjianfeng@byosoft.com.cn>:

Marvin,
ImageBase was saved in DR2 to help HOST debugger to locate the image base more easily, even though the HOST debugger could find the image base through searching the DOS image signagure.
The reason choosing DR1 and DR2 to save PDB & ImageBase contexts is just implementation only. And it could co-work with Debug Agent Lib implementation and SIMCS.  I am not sure whether is could co-work with INTEl System Debugging tools or not.
Good day Jeff,

Thanks for your response!

I've read that Intel System Debugger superseded the UDK debugging tool, maybe that was incorrect though. I use GDB. :)

I don't understand why the new PeCoffLib implementation would break the existing debugging tools?Could you explain it more details?
Please refer to the mail from Ray and my response. It is not the Image base address that is saved in DR2, but the PeCoffLib context address, and my new library simply has a new context structure for various reasons.

Best regards,
Marvin

----------------------------------------
Jeff
fanjianfeng@byosoft.com.cn
 
*From:* Marvin Häuser[mhaeuser@posteo.de]
*Date:* 2021-08-01 01:21
*To:* devel@edk2.groups.io
*CC:* Hao A Wu[hao.a.wu@intel.com]
*Subject:* [edk2-devel] SLDP: Usage of PE library context by debugger?
Good day everyone,
 
While refining the port of SourceLevelDebugPkg to my newly proposed
PeCoffLib rework (RFC upcoming), I noticed that the address of the PE
Image context is written to DR2 [1]. Because the UDK and Intel System
Studio debugging tools are closed source, I cannot verify what happens
to this value. Does the host read the library context and retrieve data
from it? If not, why is its address written to DR2? If so, this would
mean the new PeCoffLib implementation breaks the existing debugging
tools. The following questions would arise:
 
1) Which data are retrieved from the context structure? For GDB, I think
only the Image address and symbol file path are required (to load the
symbols), while PDB is saved in DR1 already.
2) Are there any plans to provide detailed documentation of the
host/client communication protocol?
3) Are there any plans to provide an open source debugger, or at least
the EDK II communication protocol portion?
 
Thank you for your time!
 
Best regards,
Marvin
 
 
[1]
https://github.com/tianocore/edk2/blob/610bcc69ed3d1e8c016332a1862465d41d95dd6c/SourceLevelDebugPkg/Library/PeCoffExtraActionLibDebug/PeCoffExtraActionLib.c#L126