Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

msvc subsystem option handling; added uefi os type #1855

Merged
merged 8 commits into from Dec 26, 2018

Conversation

Projects
None yet
3 participants
@nebulaeonline
Copy link

nebulaeonline commented Dec 24, 2018

No description provided.

nebulaeonline

@nebulaeonline nebulaeonline reopened this Dec 24, 2018

@nebulaeonline

This comment has been minimized.

Copy link
Author

nebulaeonline commented Dec 24, 2018

Fixed enum remnant

nebulaeonline added some commits Dec 24, 2018

@@ -394,6 +397,8 @@ const char *get_target_os_name(Os os_type) {
return "freestanding";
case OsZen:
return "zen";
case OsUefi:
return "uefi";

This comment has been minimized.

Copy link
@kristate

kristate Dec 24, 2018

Contributor

No tabs: 4 spaces please

This comment has been minimized.

Copy link
@nebulaeonline

nebulaeonline Dec 24, 2018

Author

Should have been taken care of by my editor. Sorry.

@kristate

This comment has been minimized.

Copy link
Contributor

kristate commented Dec 24, 2018

Can we get some background or synopsis?

@nebulaeonline

This comment has been minimized.

Copy link
Author

nebulaeonline commented Dec 24, 2018

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.

@andrewrk
Copy link
Member

andrewrk left a comment

Thanks for making this PR. I'm going to fix it up in a branch and then merge. I have a couple questions for you though - maybe you can help me figure a couple things out.


// 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"

This comment has been minimized.

Copy link
@andrewrk

andrewrk Dec 24, 2018

Member

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?

This comment has been minimized.

Copy link
@nebulaeonline

nebulaeonline Dec 24, 2018

Author

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.

This comment has been minimized.

Copy link
@andrewrk

andrewrk Dec 24, 2018

Member

If the /DEBUG flag is given to the linker, does it break something for you? Or does it merely produce a useless .pdb file?

This comment has been minimized.

Copy link
@nebulaeonline

nebulaeonline Dec 24, 2018

Author

the latter.

@@ -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 => {

This comment has been minimized.

Copy link
@andrewrk

andrewrk Dec 24, 2018

Member

is while (true) {} the best we can do for panicking under UEFI? is there no logging mechanism or anything?

This comment has been minimized.

Copy link
@nebulaeonline

nebulaeonline Dec 24, 2018

Author

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.

This comment has been minimized.

Copy link
@andrewrk

andrewrk Dec 24, 2018

Member

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.

This comment has been minimized.

Copy link
@nebulaeonline

nebulaeonline Dec 24, 2018

Author

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.

@andrewrk andrewrk added the os-uefi label Dec 24, 2018

@andrewrk andrewrk merged commit f49b45b into ziglang:master Dec 26, 2018

1 of 2 checks passed

ziglang.zig in progress
Details
builds.sr.ht: freebsd.yml builds.sr.ht job completed successfully
Details

@nebulaeonline nebulaeonline deleted the nebulaeonline:nebulaeonline branch Dec 26, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.