Specific name for shell application not loadable through shell - any reason why this may be?


Laszlo Ersek
 

On 07/08/20 21:48, JackMacWindows wrote:
Hello,
I asked a question here a few months ago about a problem I was experiencing with an application I was working on. Basically, the program would work just fine under QEMU (and after later testing, the EmulatorPkg as well), but when trying to run it on a real machine, the application would fail to run with EFI_UNSUPPORTED. This failure would happen before the application even ran - adding a print statement at the beginning of the entry point would not show anything.

Recently, I decided to try to fix this issue. After a bunch of debugging, I ended up changing the dsc/inf files so that they were the exact same as another program that worked, except for the name. This still did not work. That led me to the conclusion that for some reason the name I decided to use for the app ("CraftOS") was causing it to fail, which was verified after I changed the name to something else ("CCEFI").
Can you try:

- CraftOS (original mixed case)
- craftos (all lower case)
- CRAFTOS (all caps)

(Inspired by your CCEFI choice being all caps.)

Thanks,
Laszlo


Guomin Jiang
 

Hi Jack,

Good work first.

If it only occur at real platform, have you check if is any porting done by platform code.

In General, platform code = edk2 + platform code.

If the problem can't be reproduced in emulation platform from edk2, I guess that the platform code contain some special code do it.

Best Regards.

-----Original Message-----
From: discuss@edk2.groups.io <discuss@edk2.groups.io> On Behalf Of
JackMacWindows
Sent: Thursday, July 9, 2020 3:48 AM
To: discuss@edk2.groups.io
Subject: [edk2-discuss] Specific name for shell application not loadable
through shell - any reason why this may be?

Hello,
I asked a question here a few months ago about a problem I was
experiencing with an application I was working on. Basically, the program
would work just fine under QEMU (and after later testing, the EmulatorPkg
as well), but when trying to run it on a real machine, the application would fail
to run with EFI_UNSUPPORTED. This failure would happen before the
application even ran - adding a print statement at the beginning of the entry
point would not show anything.

Recently, I decided to try to fix this issue. After a bunch of debugging, I
ended up changing the dsc/inf files so that they were the exact same as
another program that worked, except for the name. This still did not work.
That led me to the conclusion that for some reason the name I decided to
use for the app ("CraftOS") was causing it to fail, which was verified after I
changed the name to something else ("CCEFI").

I’m glad to have been able to fix this issue, but I’m curious why the name
would cause it to fail to load. I don’t understand how the name would cause
some sort of failure only on real systems. Perhaps there is a bug in a
reference UEFI that causes the failure, that the OVMF firmware doesn’t
have. (Note: I tested the app on various UEFI versions from 2.3 to 2.8, and
none of them worked.) Or maybe that name mirrors some pattern in the PE
header that causes a failure when reading the image.

For reference, I mainly used the stable202002 release, but also tested on
various versions going back to UDK2015. I built on both macOS using gcc-5,
and Windows using VS 2019. The name that didn’t work was "CraftOS" and
the name that did work is "CCEFI".

If anyone has any ideas as to why this happened, I’d love to hear them.

JackMacWindows


JackMacWindows <jackmacwindowslinux@...>
 

Hello,
I asked a question here a few months ago about a problem I was experiencing with an application I was working on. Basically, the program would work just fine under QEMU (and after later testing, the EmulatorPkg as well), but when trying to run it on a real machine, the application would fail to run with EFI_UNSUPPORTED. This failure would happen before the application even ran - adding a print statement at the beginning of the entry point would not show anything.

Recently, I decided to try to fix this issue. After a bunch of debugging, I ended up changing the dsc/inf files so that they were the exact same as another program that worked, except for the name. This still did not work. That led me to the conclusion that for some reason the name I decided to use for the app ("CraftOS") was causing it to fail, which was verified after I changed the name to something else ("CCEFI").

I’m glad to have been able to fix this issue, but I’m curious why the name would cause it to fail to load. I don’t understand how the name would cause some sort of failure only on real systems. Perhaps there is a bug in a reference UEFI that causes the failure, that the OVMF firmware doesn’t have. (Note: I tested the app on various UEFI versions from 2.3 to 2.8, and none of them worked.) Or maybe that name mirrors some pattern in the PE header that causes a failure when reading the image.

For reference, I mainly used the stable202002 release, but also tested on various versions going back to UDK2015. I built on both macOS using gcc-5, and Windows using VS 2019. The name that didn’t work was "CraftOS" and the name that did work is "CCEFI".

If anyone has any ideas as to why this happened, I’d love to hear them.

JackMacWindows