Laszlo:
I verify the below three commands. The first generated EFI image includes DEBUG entry. Other EFI images have no DEBUG entry. Yes, DEBUG entry is added by GenFw tool. -z option can be used to remove it.

GenFw -e PEI_CORE -o test.efi PeiCore.dll
GenFw -e PEI_CORE -o test2.efi -z PeiCore.dll
GenFw -e PEI_CORE -o test3.efi --zero PeiCore.dll

Thanks
Liming

On 03/12/21 06:31, gaoliming wrote:

Laszlo:
I verify the below three commands. The first generated EFI image includes DEBUG entry. Other EFI images have no DEBUG entry. Yes, DEBUG entry is added by GenFw tool. -z option can be used to remove it.

GenFw -e PEI_CORE -o test.efi PeiCore.dll
GenFw -e PEI_CORE -o test2.efi -z PeiCore.dll
GenFw -e PEI_CORE -o test3.efi --zero PeiCore.dll

Thanks, I must have messed up my testing then.

... Does it matter if we add "--zero" directly after "GenFw", as very
first option? Probably not. I'll update the BZ (state that my testing
was wrong).

Thanks
Laszlo

Thanks
Liming

-----邮件原件-----
发件人: discuss@edk2.groups.io <discuss@edk2.groups.io> 代表 Laszlo
Ersek
发送时间: 2021年3月12日 1:30
收件人: discuss@edk2.groups.io; gaoliming@...; 'Ross Burton'
<ross@...>
抄送: bob.c.feng@...; yuwei.chen@...
主题: Re: [edk2-discuss] 回复: Non-reproducible binaries generated by
GenFw

Hi Liming,

On 03/11/21 05:44, gaoliming wrote:

Ross:
I verify -z option. It can remove DEBUG entry and make sure the

generated image be reproduced.

I tried the "--zero" option myself (as seen in the BZ), but it didn't
work. What I did was the following: in the original run of the "build"
utility, I redirected the standard output and the standard error to a
log file. Then, I located the "GenFw" invocation that produced the
"Shell.efi" binary from the "Shell.dll" file. I also checked that the
"Shell.dll" file did not contain the full pathname, embedded -- so it
was GenFw that embedded the full file path indeed.

Then, I re-run the GenFw utility myself, interactively, and added the
"--zero" flag to the command line. The output did not change,
"Shell.efi" still contained the full pathname embedded. I also couldn't
find a spot in the GenFw source code where "--zero" would have prevented
a call to WriteDebug64(), or otherwise eliminated the NB10 entry.

... So at this point I'm not sure if I simply messed up my testing. :(

Ross -- can you please confirm? Does Liming's suggestion work for you?

Thanks,
Laszlo

PlatformPkg.dsc:

[BuildOptions]
RELEASE_*_*_GENFW_FLAGS = -z

Thanks
Liming

-----邮件原件-----
发件人: Ross Burton <ross@...>
发送时间: 2021年3月11日 3:36
收件人: discuss@edk2.groups.io
抄送: bob.c.feng@...; gaoliming@...;
yuwei.chen@...
主题: Non-reproducible binaries generated by GenFw

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?

Cheers,
Ross