<TheLemonMan>
aw shit, we need one list for glibc and one for BSDs then
<ifreund>
not one per target?
<ifreund>
or something like is_libc_lib_name() but in reverse?
<TheLemonMan>
ah right, I cygwin/darwin may use some different sets of libs
<ifreund>
TheLemonMan: one other thing I'm confused about that you might have insight on, I now need to explictly add -lffi when linking libc and wayland wayland libraries while I didn't before my changes
<ifreund>
any idea what's up with that? I'm not really sure which behavior is correct
<TheLemonMan>
uh that's strange, libffi is not part of glibc by any means. what symbols are missing?
<ifreund>
none, linking succeeds but I get error while loading shared libraries: libffi.so.7: cannot open shared object file: No such file or directory
<ifreund>
(at runtime)
<ifreund>
which doesn't make sense caes ldd reports "libffi.so.7 => /usr/lib/libffi.so.7 (0x00007f4a2bf72000)"
<ifreund>
hmm, ldd reports all the other shared objects as being in /usr/lib64
<ifreund>
libffi is the only one listed in /usr/lib
<ifreund>
/usr/lib64 is a symlink to /usr/lib on my system though
<TheLemonMan>
none of the libraries you've added should depend on libffi
<ifreund>
maybe it wasn't my change specifically that changed this behavior, I'll test some other commits. Right now I'm comparing 0.7.1 with master
<TheLemonMan>
yeah, bisecting the offending commit is a good starting point
<TheLemonMan>
did you update any of the other wayland libs in the meanwhile?
<ifreund>
no, the same system libraries still work fine on 0.7.1
<ifreund>
I was right though, it wasn't my latest PR that changed this behavior, it's different on 55d235dc vs 0.7.1 as well
<ifreund>
time to do a long slow bisect I guess
<TheLemonMan>
git bisect with an automated script makes the bisection process quite painless
<TheLemonMan>
anyway, brb
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
<ifreund>
too many breaking changes between 0.7.1 and master to make a bisect practical :/
dputtick has quit [Quit: Connection closed for inactivity]
r4pr0n has joined #zig
leon-p has quit [Ping timeout: 265 seconds]
leon-p has joined #zig
motiejus has joined #zig
<mikdusan>
wth is wrong with your prompt? :P
<motiejus>
hi folks. How can I compile a bpf program with `zig cc`? Scrolling through the sources, it seems to be supported, but I can't find the right value for `-target` to generate the object file.
<motiejus>
I tried `zig cc -target bpf -Wall -Wextra -Werror -o ebpf_classid_marker.clang.o -g -O2 -c ebpf_classid_marker.c`, and got `error: UnknownArchitecture`; if I replace `zig cc` with `clang`, it works as expected
<ifreund>
motiejus: I think you need bpfel or bpfeb as the arch in the -target triple, see `zig targets`
[wtf]1 has joined #zig
<motiejus>
thanks! `bpfel` it is :)
<mikdusan>
the best thing about endian-acronyms is you have to remember their character-ordering for each archictecture. This is some huge conspiracy I tell ya.
[wtf] has quit [Ping timeout: 240 seconds]
[wtf]1 is now known as [wtf]
<motiejus>
git grep bpfel | tail -1
<motiejus>
src/zig_llvm.h: ZigLLVM_bpfel, // eBPF or extended BPF or 64-bit BPF (little endian)
<motiejus>
easy enough ;)
<ifreund>
git bisect says 6 more steps left :)
<mikdusan>
motiejus: `zig targets`
<motiejus>
thanks mikdusan and ifreund, that worked.
<motiejus>
another question: I started dabbing with https://github.com/ziglang/zig/issues/7915 (add `zig ar` sub-command, which just starts clang's ar); Andrew added a label "contributor friendly"; does it mean it is a reasonable request and has a chance to be merged if proposed?
[wtf] has quit [Ping timeout: 260 seconds]
<ifreund>
motiejus: yeah, that feature is considered desireable and easy for someone new to the zig codebase to work on
<ifreund>
I say go for it!
<noam>
mikdusan: nothing? :P
<mikdusan>
hmmm it would be nice if `git commit` added as comments or something HEAD's commit message for easy reference
<mikdusan>
during editing
<ifreund>
noam: your powerline glyphs are a little funky/misaligned
* noam
shrugs
<ifreund>
mikdusan: you can totally make your editor do that :P
<mikdusan>
yeah the '>' thingee sticks out above and then highlighting makes it look like the font is also shifted a pixel up
<mikdusan>
ifreund: but I am lazy
zenkuro has joined #zig
<ifreund>
guess you just gotta keep opening up another terminal to run git show then :P
<mikdusan>
hhahah
<ifreund>
actually, my editor lets me run git show in the editor and have the output show up in a new buffer
<TheLemonMan>
I'm more and more convinced that we should write down the syscall stubs (and the clone impl) in some stand-alone .S file
<TheLemonMan>
andrewrk, what do you think? would that be hard to integrate into the build system?
<andrewrk>
still catching up on the conversation
<TheLemonMan>
well, the problem is that we're hitting a few LLVM bugs in the inline asm handling when targeting SPARC, but in general we'd have some leaner and faster syscall entry points where we can precisely control how the parameters are forwarded to the kernel
<TheLemonMan>
and clone() has a huge problem, it's defined as a naked function... in c.zig
<TheLemonMan>
the problem is that, when optimizations are turned on, you can't really call a naked function defined in the same CU
<TheLemonMan>
because LLVM sees trough all your shenanigans (eg. casting the fn to a non-naked CC) and eventually does something bad with it
<TheLemonMan>
such as corrupting the input registers/frame
<TheLemonMan>
you also wrote a comment about that in c.zig heh
notzmv has joined #zig
<andrewrk>
ifreund, are you trying to upgrade river from 0.7.1 to master branch?
<ifreund>
andrewrk: no, I was just making a 0.8.0 branch for zig-wayland so someone who was interested could play around with upgrading the code generation to use the new std.fmt fanciness
<ifreund>
to be clear, everything works fine if I explicitly link libffi, it just seems weird that the behavior of lld changed
<andrewrk>
agreed
tefter has quit [Ping timeout: 240 seconds]
tefter has joined #zig
<mikdusan>
ifreund: do you have anything in progress re: *bsd hosted-lib linking ? it's pretty much broken now and I need to get some fixes in
<andrewrk>
TheLemonMan, ok I'm thinking about the inline asm thing. damn, I really like the tight integration with inline asm. are you sure we can't fix the problems with a some combination of language modifications + lowering to LLVM IR in a more careful way?
hiljusti has quit [Ping timeout: 260 seconds]
notzmv has quit [Ping timeout: 240 seconds]
<TheLemonMan>
I'll try to dig a bit more to see if LLVM can be convinced to leave the naked fns alone
<ifreund>
mikdusan: No I haven't started anything yet, sorry for breaking things
<ifreund>
I'll probably get to it later this evening unless someone else does it first
<ifreund>
It should be as simple as adding a function to std.Target that returns the list of libc components that need to be linked and then using that over the current hardcoded list
<andrewrk>
you could also put them in src/target.zig depending on whether it seems like a compiler implementation detail, or an interesting property of a particular target
<ifreund>
ah, yeah src/target.zig is probably better
<andrewrk>
TheLemonMan, I'm reluctant to give up the property that a compilation can start with .zig code as a root source file, and load only other .zig files, and be able to do syscalls. I don't want to shut down your efforts here but I do want to make sure we're exploring all the options. we'd definitely be giving up a certain cross-section of simplicity by trying to bring in assembly files into the mix
<andrewrk>
but yeah I just re-read my own comment on top of fn clone and that TODO has just been sitting there for years now
<andrewrk>
I think the first question that needs answering is, which of the three problems is this? (1) a soundness problem in the language? (2) a problem with lowering to sound LLVM IR? (3) bug(s) in LLVM?
<andrewrk>
I might want to recruit Martin to help with this question
<mikdusan>
ifreund: re: some libs are omitted if specified like -lcrypt; I saw ref in irclogs recently but didn't pay attention, but do you know why we eat libc library names and prevent them from going into system_libs ?
guccimayne has left #zig ["Leaving"]
<andrewrk>
mikdusan, it's because until now we wanted to be in charge of providing libc
<andrewrk>
so we treated "link libc" as a single bit, yes/no
<andrewrk>
I still think that might be the right approach
<mikdusan>
I'm thinking we let all -lfoo go into system_libs, and then at link-time, we dupe system_libs, and pull out the ones that are ordered, add to argv, then in ordered fashion add the special ones to argv
<mikdusan>
i worded that goofy. but this lets us not assume which libs need to be on command line
<andrewrk>
if zig is providing libc, we need to know if -lfoo is a non-libc system dependency, or if it is one that we will be providing with libc
<mikdusan>
sure but we need to _track_ if crypt or pthread or m is needed
<andrewrk>
why?
<mikdusan>
and isn't that the spec'd by build.zig author ?
<mikdusan>
well right now,
<mikdusan>
`-lm -lpthread -lc -dl -lrt -lutil` is added
<TheLemonMan>
andrewrk, I hear you, having everything into a single .zig file is a nice property
<mikdusan>
and we don't need to link .so if not needed, right?
<TheLemonMan>
in my notes I've found that you can avoid many problems by 1) marking the function noinline 2) not putting an unreachable as last instruction
<TheLemonMan>
the former avoids inlining and the latter... well, that's sort-of correct as you're messing with the reachability analisys
<TheLemonMan>
I think clone() would be ok with just a noinline
<TheLemonMan>
__clzsi_arm32 is another example of this problem, as I wrote in clzsi2_test.zig
<andrewrk>
back in a bit, food
<TheLemonMan>
alright, stage1 is also buggy af and prevents you from calling a naked function even after casting it
<motiejus>
andrewrk: thanks for your comment in https://github.com/ziglang/zig/issues/7915 ; but I missing on what happens once the command-line arguments are parsed and interpreted? My intial idea was to detect `zig ar`, and then call llvm-project/llvm/tools/llvm-ar/llvm-ar.cpp's `int main`.
<TheLemonMan>
motiejus, you may want to talk with kubkon about that, he re-implemented part of the archive reading for his linker work
<motiejus>
ok, what's the protocol? is he on IRC? Shall I ping him on github?
<TheLemonMan>
I think he's on the Discord server
<g-w1>
he is on github and discord. he does not use irc that much
<motiejus>
I will ping on github then
<motiejus>
thanks
Exonorid has joined #zig
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
<g-w1>
motiejus: i think what is going to happen, is that zig will just use it's own ar
<g-w1>
i think kubkon already did a decoder with Zld
<motiejus>
that means, if I want an `ar`-compatible `zig` subcommand, I'd need to reimplement the front-end in zig?
<g-w1>
i think `zig ar` will be all zig
<motiejus>
i.e. `ar d`, `ar m`, etc
<motiejus>
if that's true, then it's quite a bit more involved (and does not fit/belong to src/main.zig ?)
<g-w1>
well zig already can do libraries with `build-lib` so all it would have do to is parse the args in a different way
<mikdusan>
zig puts everything into 1 executable
hiljusti has joined #zig
mokafolio has quit [Quit: Bye Bye!]
mokafolio has joined #zig
lemur has joined #zig
<ifreund>
mikdusan: We don't need to no, but I'm not sure if there's any real cost associated with doing so. This is essentially the status quo as until now we have defaulted to using the libcs shipped with zig and linking all components thereof
<ifreund>
if there is a demonstrable cost to linking 3-4 shared object that aren't used, we should reconsider this
<ifreund>
I think that's probably better done down the line, I need to wash some dishes then I will fix the build for OpenBSD
koakuma has quit [Read error: Connection reset by peer]
<mikdusan>
we also have `zig cc` drop in replacement. Start linking libs that `cc` doesn't and it won't go down well a lot of devs, imo
<mikdusan>
and sure we can diverge behavior from `zig cc` and `zig build-*`
<mikdusan>
but what's involved in knocking that list down, really? it's not much
<mikdusan>
invariant 1: link what we know or detect to be minimum libc requirement
<mikdusan>
then for each lib known to have ordering requirements, pull it out of libs-list,
<ifreund>
mikdusan: it's probably not that hard to implement, but we end up breaking all code that relies on -lc to pull in the rest of the components
<mikdusan>
add that set remaining to argv, then as needed, add each ordered lib, if it was specified.
<mikdusan>
i'm not following, which code?
<ifreund>
mikdusan: all code that links libc and uses e.g. pthreads right now
<mikdusan>
pthreads is a special case btw. can't we just say `if builtin.single_threaded == true` add pthread?
<ifreund>
what you are proposing is changing linking libc from a binary switch for *all* libc components to a more finely grained thing
<ifreund>
no?
<mikdusan>
that binary switch is precisely inadquate today
<ifreund>
yeah I agree that we should change this, I'm just explaining that this is a pretty widely breaking thing
<ifreund>
I'll just do a quick fix for OpenBSD and then look at how best to implement this
<mikdusan>
netbsd is broken too
lemur has quit [Ping timeout: 240 seconds]
<mikdusan>
status is: freebsd/dragonfly can tolerate the current list of .so always given
<mikdusan>
and openbsd/netbsd cannot because they don't have... dl and rt (iirc)
<ifreund>
mikdusan: ok, so the current list minus dl and rt is should be fine for openbsd/netbsd for now?
<mikdusan>
just fyi, I'm not looking to make you do the work for that fix. it's easy enough to do. I'm more interested in how we solve this
<ifreund>
mikdusan: hmm, one problem with making this switch non-binary, this would require changing std.builtin.link_libc from a bool to something else
<ifreund>
or adding other bools for libm, libpthread, etc
<g-w1>
does river work on openbsd?
<ifreund>
very doubtful, it does work on freebsd though (and is packaged ;D)
<mikdusan>
ifreund: hmm not grok'ing that. I assumed the quick fix would be a switch on os.tag around the currrent src.link.Elf code
<mikdusan>
and what about the other funky libs xnet, resolv
<mikdusan>
crypt
<ifreund>
mikdusan: oh that "one problem" wasn't regarding the quick fix
<ifreund>
yeah, just a switch on os.tag but in src/target.zig cause that's a little cleaner
<ifreund>
I don't really know what's up with xnet/resolv/crypt
<ifreund>
is libc required to provide those?
notzmv has joined #zig
<mikdusan>
well I'll answer that more generally. if zig std references symbols, on some platforms (like macos) they're all fronted by one libSystem. on others they're mostly offered by libc, then some platforms deviate which lib which sym is found in,
<mikdusan>
so the answer is always going to be host-specific
sord937 has quit [Quit: sord937]
<mikdusan>
I view this as a problem that `./configure` or `cmake` has generally solved
<ifreund>
which is why our current binary switch is very convienient for cross compiling and cross platform code
recalloc has joined #zig
<mikdusan>
cross-compiling is a little different, zig is in full control there
<mikdusan>
but host-libc not so much
leon-p has quit [Quit: leaving]
<ifreund>
when cross compiling we always link all the libc components no?
<recalloc>
I'm looking into the STL and found that some structs use const `Self = @This()`, and others use `This` instead. Is intentional, something historic, or something else?
<g-w1>
stl? ;)
<recalloc>
sorry, std :)
<g-w1>
well anyways, i don't think its intentional.
<recalloc>
oh wait, I don't see `This` used at all actually. Where did I see it, then?
<ifreund>
grep doesn't find any `const This = @This()` in the std
<mikdusan>
ifreund: there's many kinds of cross. glibc .so or musl static?
<g-w1>
maybe just self: @This()
<recalloc>
I was going to ask which is current practice, but I guess I've answered my own question
<ifreund>
mikdusan: glibc is the only one one where we provide multiple so files
<mikdusan>
ifreund: for glibc cross the result: m.so, c.so, dl.so, rt.so, ld.so, util.so <-- so the same set
<ifreund>
recalloc: I think best practice is to not use `const Self = @This()` unless writing generic code
<ifreund>
mikdusan: yep, I copied the full list I'm using from there
<ifreund>
because that was the status quo for almost all zig code linking libc
<recalloc>
Looks like generic code use `Self = @This()` too, at least specifically struct-returning-functions.
<oats>
Why is `const = @This();` discouraged?
<g-w1>
because its wrong syntax
<oats>
Oh uhhh const whatever
<g-w1>
and its verbose
<oats>
Shaddup I'm on my phone :P
<ifreund>
recalloc: yes, generic code is the only place I'd recomment the `const Self = @This()` convention
<oats>
Should one just use @This() directly at point-of-use?
<oats>
Such as in a top-level struct
<ifreund>
no, just use the name of your struct and avoid @This() unless it is needed
<g-w1>
or const FileName = @This(); for struct files
<oats>
OK so struct files are a valid use for that
<mikdusan>
ifreund: so looking at glibc source code, seems that { crypt, resolv } are part of it
<mikdusan>
but not part of zig's bundled glibc
<ifreund>
hrm, does musl provide those?
* mikdusan
downloads it....
<ifreund>
iirc it doesn't and for some good reason or another
* mikdusan
boots alpinelinux to poke around a musl-based os
<ifreund>
a quick test on net/open bsd would be appreciated if you wouldn't mind
<mikdusan>
looks like crypt/ subfolder in musl official sources. no resolv/ though
<mikdusan>
heh alpine has a bunch of .a that have this content:
<mikdusan>
!<arch>
<mikdusan>
and that's it. for crypt.a, dl.a, m.a, ptherad.a, resolv.a, rt.a, util.a xnet.a
* mikdusan
shrugs
<mikdusan>
checking that PR now
<ifreund>
mikdusan: musl puts everything in libc.so
* mikdusan
watches as zig boils oceans and evaporates 28 GB of my RAM
<mikdusan>
yup that PR looks good
<mikdusan>
#8754
<mikdusan>
pronouns. what could go wrong?
<mikdusan>
ifreund: btw, thanks for the fix
<mikdusan>
now we just need some ci for openbsd, netbsd and dragonfly
<ifreund>
mikdusan: no problem, thanks for testing
<ifreund>
yeah, CI for those would have prevented this in the first place
novakane has quit [Quit: WeeChat 3.1]
waleee-cl has joined #zig
ur5us has joined #zig
Spex_guy has joined #zig
<Spex_guy>
Hey, anybody know how write-after-read memory hazards affect performance? Specifically looking at a loop like this: https://zig.godbolt.org/z/zbEjbqeYe
<Spex_guy>
I haven't been able to find any resources on it, but it seems like in theory, since the address is computed, the processor wouldn't realize these are the same memory address until late in the pipeline. Once that happens it would have to flush and restart at the read, similar to a branch mispredict. Unless the issue unit is smart enough to avoid
<Spex_guy>
this somehow?
<mikdusan>
I have no idea about any of that subject but maybe my googlefu is of help:
<Spex_guy>
Yeah, I couldn't find much that was relevant. That lecture and most of the other things I found are about register write-after-read, which is usually resolved in the rename unit before issue, so in that case the processor already knows about the dependency and can delay one of the instructions.
nvmd has joined #zig
tefter_ has joined #zig
zenkuro has joined #zig
tefter has quit [Ping timeout: 252 seconds]
Akuli has quit [Quit: Leaving]
<ifreund>
ooo, #8756 looks juicy
bitmapper has joined #zig
txdv has quit [Ping timeout: 252 seconds]
v0idify has joined #zig
<ifreund>
hmm, now that we have std.mem.sliceTo() I feel like std.mem.span() should be std.mem.slice()
Nypsie has quit [Ping timeout: 258 seconds]
v0idify has left #zig [#zig]
Nypsie has joined #zig
<andrewrk>
ifreund, I think I was considering renaming slices to spans
<andrewrk>
std.mem.span was "let's try this name on"
<andrewrk>
but I agree with you
<ifreund>
andrewrk: cool, I'll get that PR'd tomorrow
<ifreund>
and I should probably update the std for these changes as well
<ifreund>
pretty happy with how the API of sliceTo() turned out :)
<mikdusan>
👍👍 for shorter stack traces. oh yes.
<mikdusan>
pgup/dn keys are finally gonna get a break :)
<g-w1>
which pr is that?
<g-w1>
or is it committed?
<mikdusan>
i think this one did it: c3d4733a00880e2c757b61b66ba18d9b6753aa11
<g-w1>
thanks
ur5us has quit [Ping timeout: 250 seconds]
v0idify has joined #zig
<v0idify>
i'm getting "segfault at address 0x10" when trying to get something from a std.event.Channel, i initialized just like in the tests
<andrewrk>
if you're writing a shell, std.ChildProcess might be too high level of an API. you might want to reach into std.os for that
<g-w1>
Thats what i thought at first, but then thought it could also be fun to improve ChildProcess. Ill take a look at std.os
<andrewrk>
it's possible that we could add that feature to std.ChildProcess. the first step would be doing an inventory of what features are possible on various targets
<andrewrk>
some targets in particular to consider are: Windows, WASI
<andrewrk>
can still add a feature that is not supported everywhere, but requires special consideration
<g-w1>
seems like windows has pipes (at least powershell has them, so it must be able to be done), not sure about wasi
Exonorid has quit [Remote host closed the connection]