msvc subsystem option handling; added uefi os type #1855
Conversation
…into nebulaeonline
|
Fixed enum remnant |
src/target.cpp
Outdated
| @@ -394,6 +397,8 @@ const char *get_target_os_name(Os os_type) { | |||
| return "freestanding"; | |||
| case OsZen: | |||
| return "zen"; | |||
| case OsUefi: | |||
| return "uefi"; | |||
There was a problem hiding this comment.
Should have been taken care of by my editor. Sorry.
|
Can we get some background or synopsis? |
I am attempting to write zig code that runs as a uefi application (such as a hypervisor, 2nd stage bootloader or OS); as such, it was necessary to modify some of the lld options. Andrew requested a more robust change than I was doing initially (such as enumerating the subsystems supported by lld-link and exposing those options on the command line). I then ran into an issue where assumptions were made about the presence of libc with all c code. A bit of other minor frustrations, and here we are. |
|
|
||
| // These are n actual command lines from LINK.EXE UEFI builds (app & driver) to be used as guidance cleaning | ||
| // up a bit for building the COFF linker args: | ||
| // /OUT:"J:\coding\nebulae\k\x64\Release\k.efi" /LTCG:incremental /Driver /PDB:"J:\coding\nebulae\k\x64\Release\k.pdb" "UefiApplicationEntryPoint.lib" "UefiRuntimeLib.lib" "UefiHiiLib.lib" "UefiHiiServicesLib.lib" "UefiSortLib.lib" "UefiShellLib.lib" "GlueLib.lib" "BaseLib.lib" "BaseDebugPrintErrorLevelLib.lib" "BasePrintLib.lib" "UefiLib.lib" "UefiBootServicesTableLib.lib" "UefiRuntimeServicesTableLib.lib" "UefiDevicePathLibDevicePathProtocol.lib" "UefiDebugLibConOut.lib" "UefiMemoryLib.lib" "UefiMemoryAllocationLib.lib" "BaseSynchronizationLib.lib" "UefiFileHandleLib.lib" /IMPLIB:"J:\coding\nebulae\k\x64\Release\k.lib" /DEBUG:FASTLINK /BASE:"0" /MACHINE:X64 /ENTRY:"EfiMain" /OPT:REF /SAFESEH:NO /SUBSYSTEM:EFI_APPLICATION /MERGE:".rdata=.data" /NOLOGO /ALIGN:32 /NODEFAULTLIB /SECTION:".xdata,D" |
There was a problem hiding this comment.
It looks like this example outputs a pdb file, but earlier you disabled the /DEBUG flag for the UEFI subsystem. Is there a reason it has to be disabled, even when --strip is not passed?
There was a problem hiding this comment.
There is no debugger at that point to make use of the pdb file, at least not without more work I should say. And the command lines were taken from example solution files provided with the VisualUefi toolkit; The inconsistency was overlooked on my part, but I did intentionally disable debugging on uefi targets.
There was a problem hiding this comment.
If the /DEBUG flag is given to the linker, does it break something for you? Or does it merely produce a useless .pdb file?
| @@ -10,7 +10,7 @@ pub fn panic(msg: []const u8, error_return_trace: ?*builtin.StackTrace) noreturn | |||
| @setCold(true); | |||
| switch (builtin.os) { | |||
| // TODO: fix panic in zen. | |||
| builtin.Os.freestanding, builtin.Os.zen => { | |||
| builtin.Os.freestanding, builtin.Os.zen, builtin.Os.uefi => { | |||
There was a problem hiding this comment.
is while (true) {} the best we can do for panicking under UEFI? is there no logging mechanism or anything?
There was a problem hiding this comment.
I'm not yet sure if output is dependent upon which uefi toolkit is used. I am investigating gnu-efi a bit closer, but as I'm a BSD/MIT/Apache person myself, admittedly I know very little about it.
There was a problem hiding this comment.
In https://nebulae.online/kzig.zig.txt you're calling this Print function. Is that function always guaranteed to exist in the UEFI environment? That could be used to print the panic message, at least.
There was a problem hiding this comment.
Looks like gnu-efi has a ton of the same Intel code as edk-II, so it may be as simple as Print vs _Print. I think it's safe to assume there's a better panic implementation.
No description provided.