ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
daurnimator has quit [Quit: WeeChat 2.3]
daurnimator has joined #zig
<andrewrk>
daurnimator, agreed - writing drivers and utilities in zig is a supported use case
<andrewrk>
but that's not ruled out by some of the standard library depending on kernel32.dll
<andrewrk>
even so - I also agree with you that, when possible, it would be better to depend on ntdll rather than kernel32
<andrewrk>
to be honest I wasn't aware of the hierarchy until now
<andrewrk>
so all the system32 dependencies should be revisited
<andrewrk>
oops, I meant kernel32
<daurnimator>
andrewrk: IMO it's similar to the choice on (e.g.) linux to use libc or not
<andrewrk>
that makes sense
<daurnimator>
andrewrk: for implementing e.g. zig's "open a file" function, do we want to use libc's fopen? or libc's open()? or the syscall?
<daurnimator>
I see scenarios where I might want any of those options...
<daurnimator>
NtOpenFile vs NtCreateFile is a different function instead of posix's `O_CREAT` option.
<daurnimator>
except NtCreateFile has a the FILE_OPEN flag. which is like the inverse of O_CREAT. so there's no reason to use NtOpenFile
<andrewrk>
daurnimator, in answer to your question: when linking libc, use libc's open. otherwise use the syscall. I don't see any reason for the standard library to depend on fopen
<daurnimator>
andrewrk: because sometimes you need to pass a FILE* to an external library
<andrewrk>
then the user can do fdopen, and do that
<knebulae>
Well, I've mostly implemented what I wanted to but it has brought me to an interesting impasse. Namely, bootstrap.zig. It seems hardcoded for certain entrypoints, so I'm not sure the best way to propagate a custom entry point from the command line through to this point. For UEFI, the linker flags were straightforward, but I can see many instances where a non-standard entrypoint is provided, and not just with UEFI/Windows.
<daurnimator>
andrewrk: true. but now imagine the reverse from a callback: what if a library calls into zig with a FILE* argument and says "please write your data here"
<andrewrk>
daurnimator, then the zig code can use the appropriate libc API and do it
<daurnimator>
andrewrk: fair.
<daurnimator>
I was more thinking that you'd have a "wrap File* in zig OutputStream" function.
<andrewrk>
you could still do that, and it would work fine
<daurnimator>
yep. should be easy to create a OutStream.writeFn that used c.fwrite
<andrewrk>
knebulae, I think we can work this out in a reasonable way. let me switch mental contexts here to your situation
<knebulae>
no rush man.
<andrewrk>
so what's the custom entry point? is there no standard for UEFI?
<andrewrk>
I think what we can do is adjust the logic for bootstrap.zig for when the target OS is UEFI
<daurnimator>
andrewrk: how does "use libc" get set in zig?
<daurnimator>
(and how does it relate to targets?)
<andrewrk>
@import("builtin").link_libc is set to `true` or `false` depending on whether you link against libc
<andrewrk>
for macos and freebsd it's always true
<daurnimator>
andrewrk: how does that work when you might be just compiling zig to a .o file?
<andrewrk>
you have to tell zig whether you plan to link libc or not
<daurnimator>
andrewrk: how do you do that?
<andrewrk>
--library c
<daurnimator>
okay
<daurnimator>
so we'd do similar for `--library kernel32` ?
<andrewrk>
libc is special - for other libraries such as kernel32 you can implicitly link against them by calling `extern "kernel32"` functions
<daurnimator>
andrewrk: why is libc special in a way that kernel32 isn't?
<andrewrk>
based on a little bit of digging just now, I'm not sure we need any dependencies on kernel32
<andrewrk>
because libc requires startup files.
<andrewrk>
for example we have to link against crt1.o
<andrewrk>
and it requires special system detection
<daurnimator>
andrewrk: kernel32 provides the stable+documented APIs for windows. only *some* ntdll level calls are stable. and most are super sparse on documentation
<daurnimator>
andrewrk: sort of like freebsd I guess? it *has* syscalls, but they're not a stable API, so we always link against libc? (this is a guess)
<andrewrk>
where are you getting that information?
<daurnimator>
andrewrk: e.g. try and find docs on NtCreateUserProcess
<andrewrk>
that's a good example. first of all I notice that the wine implementation has code, rather than simply forwarding the call to NtDll
<andrewrk>
...for CreateProcessW, that is
<daurnimator>
andrewrk: IIRC you also need kernel32 to do thing like write/read from a cmd.exe terminaal
<daurnimator>
anyway, I don't think this is really worth your time right now
<daurnimator>
back to copy ellision with you ;)
<knebulae>
andrewrk: EfiMain
<andrewrk>
knebulae, ok, so when the Codegen::zig_target OS is uefi, then we look for EfiMain in the root source file. if we find it, then don't enable bootstrap.zig. this enables a custom EfiMain. but if we don't find it, then we do include bootstrap. and then in bootstrap, we add EfiMain and conditionally export it if builtin.os == builtin.Os.uefi
<andrewrk>
knebulae, does the normal main prototype make sense for uefi? if so we can have bootstrap then call the main function like normal. otherwise you can come up with the correct prototype for a uefi main that goes into the root source file that bootstrap.zig will call into
<knebulae>
andrewrk: prototype is non-standard: EFI_STATUS EFIAPI UefiMain(IN EFI_HANDLE image_handle, IN EFI_SYSTEM_TABLE* system_table). I've also seen EfiMain, which may be what the gnu equivalents use.
<andrewrk>
knebulae, in this case it might just make sense to have zig give a compile error when UefiMain is not exported from the root source file
<andrewrk>
when the target os is uefi
<knebulae>
ok
rayman22201 has quit [Ping timeout: 256 seconds]
ForLoveOfCats has quit [Quit: Konversation terminated!]
knebulae has quit [Ping timeout: 250 seconds]
knebulae has joined #zig
Ichorio has quit [Ping timeout: 244 seconds]
emekoi has joined #zig
<emekoi>
daurnimator, is NtosKrnl part of the native api along with ntdll?
<daurnimator>
emekoi: I'm not sure I understand your question there. NtosKrnl.exe *is* the kernel.
<knebulae>
emekoi: maybe more appropriate is NtosKrnl is the kernel itself, ntdll is the API surface exposed by that kernel.
<knebulae>
emekoi: and every ntXXX function has an analogous zwXXX function which is intended to be called from ring0 code (i.e. driver / kernel code).
francis36012 has quit [Ping timeout: 245 seconds]
zachcarter has quit [Read error: Connection reset by peer]
emekoi has quit [Remote host closed the connection]
daurnimator has quit [Ping timeout: 250 seconds]
daurnimator has joined #zig
allan0 has quit [Ping timeout: 244 seconds]
commander has joined #zig
Ichorio has joined #zig
odc has quit [Ping timeout: 250 seconds]
odc has joined #zig
zachcarter has joined #zig
steveno has joined #zig
steveno_ has joined #zig
steveno has quit [Ping timeout: 252 seconds]
IntoxicatedHippo has joined #zig
<IntoxicatedHippo>
Is it possible to generate the branches of a switch statement using an inline loop?
<IntoxicatedHippo>
Or just generate code in general I guess.
Hejsil has joined #zig
<Hejsil>
IntoxicatedHippo, Chaining ifs is your best bet. There is no way of generating switch cases
<IntoxicatedHippo>
I was hoping to generate a function at compile time based on a string.
<Hejsil>
Well, chaining ifs is a fine solution.
<andrewrk>
Hejsil knows a thing or two about that :)
<Hejsil>
Hmmm. I think i've only actually tried generating code for brainfuck programs
<andrewrk>
Hejsil, for #1842 you need to add the @import in test/behavior.zig
<Hejsil>
Aah, right
<andrewrk>
the fix looks correct though
<Hejsil>
Ye, only made a PR because I wasn't sure it was
<Hejsil>
With the fn ptr fix and my commit on comptime_int support for formatType, the REPL can now use comptime_int and the interfaces :)
<andrewrk>
neat!
<andrewrk>
Hejsil, I think 260c3d9c broke master
<Hejsil>
Hmm, i see
<andrewrk>
oh, you fixed this in #1842
<Hejsil>
Oooh, yes i think i pushed the test for fn ptr printing by mistake
<Hejsil>
Note to self. Avoid working on to many things
<Hejsil>
(I thought i stashed correctly)
<andrewrk>
no worries
<andrewrk>
with the automatic download page updater, mistakes like this are not really painful, since it has the latest successful build
qazo has joined #zig
halosghost has joined #zig
IntoxicatedHippo has quit [Remote host closed the connection]
qazo has quit [Ping timeout: 250 seconds]
Hejsil has quit [Quit: Page closed]
<knebulae>
Any thoughts on u16 string literal handling (still beating the uefi horse)?
<andrewrk>
knebulae, if we don't already have one, you can make a function that works at compile time, to provide utf16le string literals
<knebulae>
ok
<andrewrk>
const s = std.unicode.whatever_its_called; and then you can use s("hello from zig\n\x00")
<andrewrk>
or if you want null terminated, have it return a [*]u16 and it can do that for you too
<knebulae>
I totally dig your language btw. Exactly what I was looking for.
<andrewrk>
thanks
<andrewrk>
until https://github.com/ziglang/zig/issues/425 is resolved, you'll have to call the function with `comptime` if you're not in an implicitly comptime context, such as inside a function body
<knebulae>
I see. Makes sense.
<andrewrk>
if we had such a function it would be in std.unicode somewhere, and if we don't then the functions in there could be used to implement it
<andrewrk>
also consider u16 instead of c_ushort, although I don't think there will ever be a difference for this target
<knebulae>
I only used c_ushort because all the string literals used before disabling uefi boot services (and running bare, as they say), will definitely be passed to/from C. But I agree with your point that for this target it likely won't matter. It should be noted too that getting this right is important though, as ARM in 64LE mode is shipping with UEFI2 and ACPI support. So we're not totally platform agnostic. But in this context, LE ARM will have the same
<knebulae>
byte layout with a u16 or a c_ushort.
<andrewrk>
knebulae, you added the UEFI os to target.cpp right?
<andrewrk>
I think you must have seen this because you would have got a compile error if you didn't add a case
<knebulae>
I added a fallthrough case above OsWindows
<knebulae>
for OsUefi
<andrewrk>
that sounds fine. we can add per-architecture logic in the future if necessary
<andrewrk>
e.g. if ARM wants to define the sizes differently we can just check target->arch in this function
<andrewrk>
anyway, sounds like you know what you're doing :)
<knebulae>
There's also the option to directly expose certain LLVM options instead of a blanket "pass this to llvm" arg. Things like entry point, linker subsystem, executable format. Might be easier in the long run. People like to build weird things for weird targets. It should be just as easy with zig as it is with gcc or clang.
<andrewrk>
knebulae, yes - the "pass this to llvm" arg is not intended to be used by anyone other than as a workaround
<knebulae>
understood
<andrewrk>
so if you have to use it, please make sure there is an open zig issue explaining why you're forced to do it
<knebulae>
I see.
<andrewrk>
for entry point you can use a linker script
<andrewrk>
the other stuff you mentioned is planned
<knebulae>
Honestly, if the llvm options had been more open, I likely could've accomplished what I wanted without modification to the code. Specifying the entry point, object format, stack alignment, stack size (which is hardcoded, but I've seen the comment), etc. would have allowed me to coerce zig to produce the output I wanted.
<knebulae>
And understood on the linker script as well.
<andrewrk>
I agree with you
<andrewrk>
I'm happy that we're gaining this UEFI os target though
<knebulae>
If you want a full stack in zig, it had to be done.
<andrewrk>
at this stage in zig (0.3.0) the project is largely use-case driven. so I really appreciate people who bring new use cases and push forward on the issues that block that use case
<knebulae>
Just trying to do my part. Lol.
<knebulae>
andrewrk: I know this should be easy, but I'm looking for you to maybe short-circuit this for me. It appears that you start making decisions about entrypoint/main in gen_root_source() in codegen.cpp. Is that a correct assumption or do I need to backtrack further?
<andrewrk>
knebulae, yes that's right. I apologize for the logic being a bit messy
<andrewrk>
if you grep for those flags there are a couple other places that might be relevant. for example look at add_fn_export in analyze.cpp
<knebulae>
right. I'm trying to modify the code while not being an expert. It's a fine line to walk. I'd prefer my PR to be mostly silent. Ninja-like.
<knebulae>
I'm mostly kidding of course. I just don't want to break anything.
<andrewrk>
much appreciated :)
<knebulae>
andrewrk: what is the intended handling of Zen? Should it have an entrypoint? It was reporting OsUknown, so I added an enum, then I had second thoughts about side-effects or other regressions. I don't want to break other people's builds.
<andrewrk>
knebulae, don't worry about that one too much, that's aiwakura's OS
<andrewrk>
I'm pretty sure we have an OsZen enum item for it
<andrewrk>
in target.hpp
<andrewrk>
I don't think I understand your question
<knebulae>
My question actually was related to build handling. The way it is setup, zen returns OsUnknown, which then returns OsFreestanding, which causes only the panic function to be generated in gen_root_source()
<knebulae>
So, by changing the return from OsFreestanding to OsZen, but not modifying codegen.cpp to handle that case, I broke aiwakura's build.
<knebulae>
I think I answered my own question. Sorry for thinking out loud.
steveno_ has quit [Ping timeout: 268 seconds]
qazo has joined #zig
qazo has quit [Ping timeout: 250 seconds]
oconnor0 has joined #zig
Zaab1t has joined #zig
return0e has quit [Ping timeout: 246 seconds]
<knebulae>
andrewrk: what is your setup for debugging on Windows? I'm trying to build a debug build, but that conflicts with the LLVM libraries, which are not debug builds (which I can remedy, of course).
<andrewrk>
knebulae, I have a separate debug build of llvm
<knebulae>
that's what I figured
return0e has joined #zig
very-mediocre has joined #zig
<andrewrk>
knebulae, on linux you can have a release build of llvm and debug build of zig, but I was unable to figure out how to do that on windows
SimonNa has quit [Remote host closed the connection]
steveno_ has joined #zig
<andrewrk>
hmm. ran into a bit of a snag with copy elision that would be solved with null terminated pointers
<andrewrk>
I'll see how much work that would be to implement and if it would conflict too much with my branch
wootehfoot has joined #zig
meheleventyone has joined #zig
knebulae has quit [Quit: Leaving]
rayman22201 has joined #zig
steveno__ has joined #zig
steveno_ has quit [Ping timeout: 250 seconds]
meheleventyone has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<mgxm>
andrewrk: zig-cache folder is created on osx too?
<andrewrk>
mgxm, yes. osx is one of the main motivations for zig-cache in fact
<andrewrk>
because we need the .o files sitting around for stack traces to work
<mgxm>
I wasn't able to compile on freebsd because of this
<andrewrk>
mgxm, zig-cache is independent from the cache feature you linked to
<andrewrk>
this code is talking about a global cache, and macos is made an exception because we always link system libc on that system. freebsd needs a similar exception
<mgxm>
yeah, I did that
<andrewrk>
maybe it would be good to create a function in target.cpp such as "target_requires_libc_for_syscalls"
<mgxm>
so, zig-cache is broken for other reasons
<mgxm>
sure, I'll check that
<andrewrk>
mgxm, I'm happy to help if you elaborate on the problem
zachcarter has quit [Ping timeout: 256 seconds]
<andrewrk>
if it helps - the local zig-cache directory is never read from; only written to
<andrewrk>
other than e.g. passing arguments to the linker, with object files located in there
<mgxm>
andrewrk: thank you, I'll try to do that reading the code first
<mgxm>
doing that I can get more understanding of the code
<mgxm>
but you be sure that I'll come back here to ask for help :)
<mgxm>
yeah, It's helps a lot... I was confusing wit the other cache
<andrewrk>
I tried to get rid of it, but ended up needing it for macos stack traces
<andrewrk>
in the commit history there are actually a couple commits where it's gone, and then I had to bring it back
<mgxm>
and how it works on linux?
<andrewrk>
zig-cache works the same on all targets, for consistency
<andrewrk>
the other motivation for having it is so that it can leave the test binary around after `zig test` so you can e.g. run it with a debugger
<mgxm>
oh, I got
porky11 has joined #zig
very-mediocre has quit [Ping timeout: 256 seconds]
knebulae has joined #zig
steveno__ has quit [Ping timeout: 245 seconds]
Zaab1t has quit [Quit: bye bye friends]
halosghost has quit [Quit: WeeChat 2.3]
<mgxm>
would you like to configure the st.ht builds?
<mgxm>
I'm already using it to test my fork
<andrewrk>
sure
qazo has joined #zig
<andrewrk>
mgxm, I believe it's already set up, if you make a pull request that adds a .build.yml
qazo has quit [Ping timeout: 250 seconds]
<mgxm>
great
<mgxm>
I asked on #sr.ht if we can override the builds folder
<mgxm>
and if they are willing to accept a patch to that
qazo has joined #zig
qazo has quit [Ping timeout: 250 seconds]
<andrewrk>
I don't consider it a blocker to using the service in zig
porky11 has quit [Quit: Leaving]
<oconnor0>
andrewk, are you "moving" zig to sr.ht?
<andrewrk>
yes but the important thing is why
<andrewrk>
jokes aside I don't think the UI is project-focused enough for it to be used as zig's source and wiki. but we're using it for mailing lists, and soon for some of the CI
<andrewrk>
it would need something close to feature parity with github before I'd consider moving the bug tracker
<oconnor0>
(I don't understand those jokes...) Cool, I'd like to see a GitHub alternative take off. And charging seems a better way to ensure you aren't the product.