ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
<knebulae>
andrewrk: so I'm having a weird problem with llvm, specifically in Driver.cpp. Despite /ENTRY:"EfiMain" being passed properly, inside llvm, when it performs linking, it is not propagating that value from the linker options (others are coming through fine). This causes lld to fail with an "entry point must be defined" error.
<knebulae>
andrewrk: the relevant code begins on line 1370 of deps/lld/COFF/Driver.cpp
<knebulae>
andrewrk: the Config->Entry value is NULL for whatever reason.
<knebulae>
andrewrk: perhaps I've misunderstood the nature of this error. I did make good progress though. Almost there.
<daurnimator>
> Blocks are expressions. When labeled, break can be used to return a value from the block:
<ross_k>
Oh, so the block starting t: is an expression which returns a type?
<daurnimator>
yes
<ross_k>
Cool, thanks
<knebulae>
andrewrk: I've tracked down the issue (via manually running lld-link on the .obj that zig creates). lld-link doesn't like my .lib files (Visual Studio 17), complaining "unknown file type". Interestingly enough, it shows the full path to the original .obj file that was used to create the .lib file (maybe that's just the way .lib archiving works).
ross_k_ has joined #zig
ross_k_ has quit [Quit: Leaving]
ross_k has quit [Remote host closed the connection]
<andrewrk>
knebulae, the LLD team is pretty active in the COFF parts of it. you could try using master branch of LLD and see if it's fixed, and if not file a bug
<knebulae>
ok
<andrewrk>
if that leads to a resolution I'll look into backporting it so that you can have it before zig 0.4.0 is released
<knebulae>
andrewrk: thank you, and I'll let you know asap.
steshaw has joined #zig
IntoxicatedHippo has joined #zig
_whitelogger has joined #zig
return0e has quit [Ping timeout: 240 seconds]
return0e has joined #zig
_whitelogger has quit [Ping timeout: 268 seconds]
_whitelogger has joined #zig
IntoxicatedHippo has quit [Ping timeout: 272 seconds]
_whitelogger has joined #zig
return0e has quit [Read error: Connection reset by peer]
return0e has joined #zig
steshaw has quit [Quit: Connection closed for inactivity]
<MajorLag>
ross_k, I think this is what you are observing: For optimization reasons, when you pass a struct by value the compiler is free to pass it as either a copy or a pointer behind the scenes and you pinky swear not to modify it. If you need to modify it you have to pass it as a pointer. I'm trying to dig up the issue for you.
<unique_id>
ross_k: As daurnimator says, all are const. If you want to mutate you'll have to make a copy (which is easily optimized out). Rust chose to let the programmer mark the field as mutable: "mut x: i32" but Zig wants to stay small so you just make a copy
mixi has quit [Read error: error:1408F10B:SSL routines:ssl3_get_record:wrong version number]
noonien has quit [Quit: Connection closed for inactivity]
mixi has joined #zig
<ross_k>
Thanks, that makes sense.
unique_id has left #zig ["Konversation terminated!"]
Ichorio has joined #zig
ross_k has quit [Ping timeout: 268 seconds]
porky11 has joined #zig
Zaab1t has joined #zig
<knebulae>
andrewrk: well, I began climbing the mountain with LLVM master this morning. Rebuilt llvm, clang, & lld. Made the necessary changes to zig for LLVM 8, and now and staring at a linking error that is obviously the result of a template gone awry somewhere, but C++ template debugging is not my strong suit at all.
<andrewrk>
knebulae, ah, sorry I didn't intend for you to have to make zig work with llvm 8, I was thinking you would just build LLD master and run that manually
<andrewrk>
btw we have a branch for that, llvm8
<knebulae>
ok.
<andrewrk>
I haven't updated it in a while
<knebulae>
Well, I'm 4 unresolved externals away from having a zig that works on LLVM 8. Lol.
<andrewrk>
knebulae, but you have an LLD built from master right?
<knebulae>
yes
<knebulae>
debug and release
<andrewrk>
can you use master branch zig with llvm 7 like normal, and then do the final link step with your newer LLD?
<knebulae>
yes
<andrewrk>
that will be enough to know if we can just try to backport the fix or if we need to make a bug report
<knebulae>
There is something interesting with library handling that I suspect is the root of my problem. If I try this the other way around, creating a library with zig and attempting to use MS-LINK for the final .efi file, MS-LINK complains that the subsystem does not allow imports; but if I don't mark the entrypoint function as an export in zig, MS-LINK can't find it. :/
<knebulae>
So perhaps there is a subtlety between simply making a function c-visible and making/marking it as an import function?
<andrewrk>
from a zig language perspective, if you don't mark a function as `export` then it's not going to show up in the object file / library at all
<andrewrk>
you can find those enum values in the source printed by `zig builtin` which dumps the contents of @import("builtin")
<knebulae>
very helpful. thank you.
<andrewrk>
based on what you've found so far, however, it seems that the default of strong linkage is fine
<andrewrk>
one clue could be that this would be the same problem faced by using Clang and LLD to create a UEFI application
<andrewrk>
so if anyone has pioneered down that path, their discoveries would apply to zig as well
<andrewrk>
however, I suspect that pioneer may in fact be you :)
<knebulae>
Well, I'm probably the only one attempting clang & EDK-II. Most people are VisualStudio/MSVC & EDK-II. People using clang and gcc are probably using gnu-efi, which is much more basic. And GPL instead of BSD/MIT.
<andrewrk>
you might also try --target-environ msvc
<knebulae>
Yeah, llvm documents which options they support and where they are progress-wise.
<andrewrk>
that communicates to zig that your idea of "The C ABI" is MSVC
<knebulae>
That option is only required if you use a generic invocation of lld. I use lld-link to avoid ambiguity.
<knebulae>
sorry, to zig; gotcha.
<knebulae>
lld has a similar option.
<andrewrk>
yeah - in summary, whenever you're trying to mix zig object/library files and MSVC object/library files/linker, best to use --target-environ msvc
<knebulae>
ok
<knebulae>
This is just disappointing. I have so much code to basically *explode* into zig, but I can't even get a basic "hello from zig" to link yet. :( Soon enough...
<andrewrk>
Zaab1t, to show that the expressions can be evaluated at compile-time
<andrewrk>
try modifying the assertion to fail and running the test
<andrewrk>
(you can copy that whole arrays test block into a file and run it with the command it shows below)
suirad has joined #zig
<suirad>
good afternoon
<suirad>
andrewrk: what is the most straightforward way to move a register into a var with inline asm in zig? also, are there any limitations of asm in comptime? i have a theory id like to prove using it
<andrewrk>
suirad, you can't do asm at comptime. if you put asm in a comptime block that is "module level assembly"
<andrewrk>
to be clear, if you put it in a top level comptime block. if you put asm in a comptime block inside a function you'll get "unable to evaluate constant expression"
<suirad>
so, to be clear, you can put asm in a top level comptime block; but you cannot inside a function. Am I understanding that correctly?
<knebulae>
I cheated a little (linked using MS link).
<andrewrk>
neat!
<andrewrk>
that u16 string literal is begging for a comptime function
<knebulae>
True, but I haven't learned any zig yet :/ lol.
<andrewrk>
knebulae, I just updated the llvm8 branch to work with trunk. tests haven't finished running yet but they're passing so far
<knebulae>
good news! I still need to figure out why lld doesn't like my libraries. I thought it might be LTCG (MS's version of LTO), but I turned that off and rebuilt, and the same problem. There is no way LLVM8 cannot read/write these .lib files(*). *Yes, there is in fact a way.
<andrewrk>
knebulae, it really might be as simple as LLD needing a new feature
<andrewrk>
and with active devs, all we need is a good bug report to make it happen
<knebulae>
I'd like to submit a PR at least with the changes I made thus far.
<knebulae>
well, maybe not.
<andrewrk>
why not?
<knebulae>
well, it doesn't produce an executable with llvm7, and if it winds up requiring an embedded llvm8 to work... Maybe just not the right time.