Andrew:

-----邮件原件-----
发件人: discuss@edk2.groups.io <discuss@edk2.groups.io> 代表 Andrew
Fish via groups.io
发送时间: 2021年3月16日 2:56
收件人: discuss <discuss@edk2.groups.io>; ross@...
抄送: Feng, Bob C <bob.c.feng@...>; Liming Gao (Byosoft address)
<gaoliming@...>; yuwei.chen@...
主题: Re: [edk2-discuss] Non-reproducible binaries generated by GenFw

On Mar 10, 2021, at 11:36 AM, Ross Burton <ross@...> wrote:

Hi,

As per https://bugzilla.tianocore.org/show_bug.cgi?id=3256, GenFw
writes non-reproducible binaries by embedding a build path. In fact in
a build of ovmf with embedded shell, this one path is the sole source
of non-determinism.

WriteDebug64() is always called in GenFw on output and that embeds
into the NB10 entry the input filename. As build paths change this is
a source of non-determinism. There already exists a --zero option to
wipe out debug paths but this is in release builds so I'm not sure
what the best solution is. I can see several options:

1) Release builds should not call WriteDebug64() at all
2) --zero should wipe the NB10 entry, and release builds should pass that
3) GenFw should support path remapping (like gcc's -ffile-prefix-map)
to turn build paths into something consistent.

Any suggestions?

This is kind of a tangent, but for clang we solved a similar problem a different
way.
1) in the build_rule.txt file we added a cd $(WORKSPACE); on the compile line
so __FILE__ is always relative to the $(WORKSPACE);

[Liming] CLANG compiler supports __FILE_NAME__ macro for the file name only. MdePkg DebugLib.h has applied this definition.

#if defined(__clang__) && defined(__FILE_NAME__)
#define _ASSERT(Expression) DebugAssert (__FILE_NAME__, __LINE__, #Expression)
#else
#define _ASSERT(Expression) DebugAssert (__FILE__, __LINE__, #Expression)
#endif

Thanks
Liming

2) We added a post build step to create a Symbols directory in the Build
output.
a) The debug directory entry paths are relative to that symbols directory.
They generally look like IA32/PeiCore or X64/DxeCore etc.
b) In the old days we would launch the debugger from the Symbols
directory so relative files got searched relative to the symbols directory.
c) Now we use the UUID we have in the
EFI_IMAGE_DEBUG_CODEVIEW_RSDS_ENTRY[1]PE/COFF debug entry. On a
Mac these mach-O UUIDs are automatically indexed by Spotlight so the
debugger can just find them. It is also possible to write a tool to lookup these
UUIDs that makes them available to the debugger.

I’m not sure it is possible to do something like this with all the toolchains, but
I wanted to at least let people know we figured out a way with clang.

[1]
https://github.com/tianocore/edk2/blob/master/MdePkg/Include/IndustrySt
andard/PeImage.h#L659

Thanks,

Andrew Fish

Cheers,
Ross