Cloudef has quit [Read error: Connection reset by peer]
Cloudef has joined #zig
stripedpajamas has joined #zig
ky0ko_ has quit [Ping timeout: 260 seconds]
ur5us has quit [Remote host closed the connection]
ky0ko_ has joined #zig
dddddd has quit [Ping timeout: 240 seconds]
<stripedpajamas>
is there a reason to use csprng instead of crypto.randomBytes if you just need (cs) random bytes ?
ur5us has joined #zig
ur5us has quit [Remote host closed the connection]
ur5us has joined #zig
ur5us has quit [Remote host closed the connection]
zippoh has joined #zig
zippoh has quit [Remote host closed the connection]
zippoh has joined #zig
zippoh has quit [Remote host closed the connection]
zippoh has joined #zig
dddddd has joined #zig
epmills has joined #zig
zippoh has quit [Remote host closed the connection]
epmills_ has joined #zig
epmills has quit [Ping timeout: 265 seconds]
epmills_ has quit [Remote host closed the connection]
epmills has joined #zig
epmills has quit [Client Quit]
zippoh has joined #zig
<daurnimator>
andrewrk: I might need some hand-holding later trying to figure out how to plumb into stage 2. I tried yesterday for a couple of hours but failed
<andrewrk>
are you trying to do libgccjit?
<daurnimator>
yeah I was
zippoh has quit [Remote host closed the connection]
<andrewrk>
that would heavily conflict with #6250
<daurnimator>
hence why I was trying on top of #6250 :)
<andrewrk>
aha!
nephele_ has joined #zig
nephele has quit [Ping timeout: 260 seconds]
nephele_ is now known as nephele
<andrewrk>
I'm happy to give tips if you don't consider it to be implicit agreement in upstreaming it
<pixelherodev>
daurnimator: what are you trying to do?
<daurnimator>
pixelherodev: get stage2 to call out to a library for code gen
<pixelherodev>
ahhh
<daurnimator>
I want to be given a Module (I think) and traverse it generating code.
<andrewrk>
you'll have to think a little differently- this compiler is designed ground up to do incremental compilation, so there's not really a point in time the Module is "finished" and passed on to a next pipeline stage
<daurnimator>
Yeah that works fine with libgccjit too
<andrewrk>
the linker layer has to react to individual Decls getting added, updated, and removed
<andrewrk>
are you planning to use the existing ELF linking code and swap out the codegen parts only?
<daurnimator>
probably/yeah.
<daurnimator>
though I wasn't sure if that would be easier or harder
<andrewrk>
so you want to look at the seam between link/Elf.zig updateDecl and where that calls into codegen.zig, and react to base.options.use_llvm (I assume you changed that to an enum that includes libgccjit)
<pixelherodev>
andrewrk: you're working on LLVM support in stage2 (#6250)?
<andrewrk>
everything but the codegen
<pixelherodev>
Do you intend to add that also?
<andrewrk>
eventually
<andrewrk>
the goal of this branch is to fully move `zig cc` to stage2 and also ability to generate windows .lib files from .def files
jicksaw has quit [Quit: ZNC is kill]
<andrewrk>
I want to unblock alexnask[m] from doing more PE stuff
<pixelherodev>
I figured out the next big thing to focus on for CBE: conditionals. That'll require a bit more internal reworking (building upon what I did for the arithmetic branch) to bring it more in line with the normal codegen flow
<pixelherodev>
given the stated intent to compile stage2 using CBE to produce the new stage1, do we still want to stick with the decision to not put in effort for readable code?
jicksaw has joined #zig
<andrewrk>
there's a lot of stuff already accumulated for CBE to catch up to x86
<andrewrk>
including debug line info
<pixelherodev>
A lot of that is trivial though
<andrewrk>
yes, I'm confident in that decision. the project to replace stage1 can involve some bespoke hacks day-of to help us on our way
<pixelherodev>
Stage1 will be nearly impossible to maintain like that
<pixelherodev>
See example test output in the new CBE arithmetic PR, and imagine that scaled up an order of magnitude
<pixelherodev>
It'd likely lead to just doing it again and basing patches off of a diff
<pixelherodev>
It might be better with partly-optimized ZIR, though
<pixelherodev>
The equivalent of -O1 -ish
<pixelherodev>
But that makes it *locally* simpler, it'd probably make the code more confusing overall
<andrewrk>
what sounds easier: using critical thinking skills to independently solve 238 open stage1 bugs, or putting on some trance music and refactoring a bunch of already working code to have better names and organization?
<pixelherodev>
Honestly? I'm not sure.
<pixelherodev>
Neither one is remotely pleasant.
<andrewrk>
I am, I hate using my brain
<pixelherodev>
It's not just refactoring.
<pixelherodev>
Names and organization aren't the only things which will be thrown off
<andrewrk>
what else?
<pixelherodev>
Fundamentally, CBE is about producing machine code masquerading as C
<pixelherodev>
That's the whole *point*
<andrewrk>
yes
<daurnimator>
oh; one fun thing I realised is that libgccjit is just codegen: it doesn't support parsing assembly. so I will actually need to call back into our stage2 assembly parsing and machine code generation for that part :)
<andrewrk>
we could even do incremental linking of .c files by using ascii art in comments to take up space!
<daurnimator>
andrewrk: or magic comments like //*// that comment/uncomment pieces :P
<pixelherodev>
I think sorting out the C code does win out ultimately, but only barely
<pixelherodev>
Inter-function borders are preserved, so the absolute worst case is manually rewriting whole functions from scratch - except every bit of their intended functionality is known, so it doesn't matter
<daurnimator>
andrewrk: and that's fine :) it should be all I need to get hello world working, right?
<andrewrk>
right
<andrewrk>
daurnimator, hmm are you sure it doesn't support inline assembly
<pixelherodev>
andrewrk: I think the one big thing regarding readability that I want to convince you is acceptable is split file generation
<daurnimator>
andrewrk: yep
<andrewrk>
that's a big limitation
<pixelherodev>
Basically, I want Module.zig functions to go into Module.c, even if everything goes in one header
<pixelherodev>
Or at least, I want that to be an *option*
<andrewrk>
daurnimator, does it at least support inline machine code?
<andrewrk>
daurnimator, if your goal is to have gcc support, here's how I see that happening: copy zig source code into the gcc project and maintain it there. periodically pull from upstream zig and refresh the port/fork
<andrewrk>
or rather, don't copy zig source code, implement a GPL version for the gcc project. that's how that development process works
<andrewrk>
this is something that would make more sense with a spec
<andrewrk>
it's a worthwhile goal to have competing implementations
frett27 has quit [Ping timeout: 264 seconds]
<daurnimator>
andrewrk: I have no desire to rewrite the parser or comptime features of zig; I'm just looking to support more targets and have an alternative to LLVM
<daurnimator>
if libgccjit doesn't work out the next middle ground would be a zir frontend for gcc.
<daurnimator>
but that would be too much work for me IMO.
omglasers2 has joined #zig
<andrewrk>
I'm not seeing libgccjit likely to be upstreamed
<GreaseMonkey>
daurnimator: i didn't see that, i guess waiting for a compressor to be written was notably less pragmatic than depending on zlib
<GreaseMonkey>
(wrt a message from a day or so ago)
_Vi has joined #zig
marnix has quit [Ping timeout: 240 seconds]
marnix has joined #zig
<daurnimator>
andrewrk: I don't see a good reason to not upstream it; but I do see good reasons to not enable by default.
<daurnimator>
andrewrk: otherwise, keeping it out of tree could provide guidance on making backends more pluggable (so we can e.g. load it with dlopen)
<andrewrk>
the goal of supporting more targets should be done directly in zig code
<andrewrk>
having a GCC implementation of zig is its own goal and makes sense to be a separate implementation from the spec
<andrewrk>
I don't see the point of libgccjit
<daurnimator>
I think having some way to make use of GCC's optimizer is as important as being able to use LLVM's optimier
<andrewrk>
there's a really efficient way to implement GCC in zig: make the language so popular that someone else does it :)
<andrewrk>
s/GCC in zig/zig in GCC/
<Michcioperz>
GCC in zig sounds like fun too
<andrewrk>
libgccjit is a great example of climbing a local maximum. waste of time IMO
<daurnimator>
if that worked, rust would have a gcc backend that was usable
<andrewrk>
it's a matter of time, someone is probably already working on a gcc implementation of rust
<daurnimator>
> Cunningham's Law states "the best way to get the right answer on the internet is not to ask a question; it's to post the wrong answer."
<andrewrk>
they have the disadvantage that the language is extremely complicated and no plan for a spec coming out soon
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
waleee-cl has joined #zig
oxymoron93 has quit [Quit: Connection closed]
marnix has quit [Ping timeout: 260 seconds]
marnix has joined #zig
jorangreef has joined #zig
<jorangreef>
fn stack_or_result_location_semantics() custom_struct { var custom_structs: [1]custom_struct = undefined; fill_in_custom_struct(&custom_structs, 1); return custom_structs[0];}fn boom_or_safe() void { var custom_struct = stack_or_result_location_semantics();}Will this allocate on the stack? If so, can Zig detect that stack memory is being
<jorangreef>
used incorrectly outside the function that allocates it?
<jorangreef>
Thanks for the explanation... would this be safe (because of RLS kicking in?): var foo: custom_struct = .{ the_number: 42 }; return .{ foo: foo };
<ifreund>
that's safe because you're making a copy of the stack variable foo
<ifreund>
I think you mean .{ .the_number = 42 } and .{ .foo = foo } by the way
<jorangreef>
Great, yes, too much JSON the past few years...
<ifreund>
result location semantics aren't really all that useful yet because you can't refer to the result location before the return statement.
<ifreund>
and they are of course a nice optimization
a_chou has joined #zig
<jorangreef>
Thanks for the pointer to that issue. I was thinking 2765 would also be really useful if you could have init functions where the stack memory in the init function (like https://gist.github.com/jorangreef/77e7c609a15c6bea2ed749340c6ae9b3) is just safely converted to the stack memory of the caller, but if Zig detects it can't for some reason then the
<jorangreef>
compiler or runtime throws.
<jorangreef>
But I think that gist is probably going too far!
<jorangreef>
I think my confusion is confusing "RLS kicking in" with simply "making a copy of the stack variable foo". Thanks again!
<tsujp>
OH FREUND YOU ARE HERE TOO
<tsujp>
henlo
<ifreund>
i'm everywhere
a_chou has quit [Ping timeout: 240 seconds]
<pixelherodev>
Muahaha?
<pixelherodev>
I feel like there should be an evil laugh after a statement like that
a_chou has joined #zig
<andrewrk>
argh, sr.ht can't build stage2 anymore due to OOM
joey152 has joined #zig
<jorangreef>
Isaac, I took another look at https://gist.github.com/jorangreef/77e7c609a15c6bea2ed749340c6ae9b3 and I don't think it's UB because I believe the struct is copied in the return value to boom_or_safe()? i.e. stack_or_result_location_semantics() returns a struct not a pointer to stack memory.
cole-h has joined #zig
<ifreund>
jorangreef: indeed, that is totally safe, you are returning a copy of the struct in the array
<ifreund>
I guess I misread the code pasted into IRC :P
xackus has quit [Remote host closed the connection]
xackus has joined #zig
<jorangreef>
(y)
marnix has quit [Ping timeout: 265 seconds]
marnix has joined #zig
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
ifreund has quit [Ping timeout: 258 seconds]
ifreund has joined #zig
klltkr has joined #zig
klltkr has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<JimRM>
Hi all - I've asked this before but cannot find the answer. I am having trouble compiling some code I found:
<JimRM>
pub var mbox: [36]u32 align(16) = []u32{0}**36;
<JimRM>
error: array literal requires address-of operator to coerce to slice type '[]u32'
<JimRM>
Can someone remind me of the issue here?
msingle has joined #zig
<ifreund>
JimRM: I think you might want pub var mbox: [36]u32 align(16) = [1]u32{0}**36;
<JimRM>
Thanks, that worked!
frett27 has joined #zig
ofelas has quit [Quit: shutdown -h now]
ofelas has joined #zig
frett27 has quit [Ping timeout: 256 seconds]
jorangreef has quit [Remote host closed the connection]
frett27 has joined #zig
Akuli has joined #zig
sawzall has quit [Read error: Connection reset by peer]
sawzall has joined #zig
<JimRM>
So I am having some trouble with embedFile on bare metal aarch64 - I build an elf file but I cannot seem to find my embedded file inside of it. I hex dump both the .elf and the .bin file I have embedded and I cannot find one inside the other.
<JimRM>
Should this work? or am I misunderstanding something?
<JimRM>
(I assumed an embedded binary file would appear as is inside of a rodata section of the elf, so a hex dump of both should allow me to find one inside the other)
<alexnask[m]>
It should appear in rodata if your executable actually uses it
<alexnask[m]>
If you only define it but never reference it it will not make it in (although I guess you could @export it explicitly)
<JimRM>
My code does reference it - the problem I am having is what I see in memory does not look anything like what has been embedded
<JimRM>
Here is a section from my symbols dump file
<JimRM>
ffff000000082fa8 l O .rodata00000008 __unnamed_1
<JimRM>
ffff000000082ef8 l O .rodata00000008 FontEmbed
<JimRM>
ffff000000083180 l O .bss00000008 LFB
<JimRM>
The FontEmbed file is much larger than the address different between FontEmbedd and __unnamed_1
leeward has joined #zig
zippoh has joined #zig
a_chou has quit [Quit: a_chou]
a_chou has joined #zig
a_chou has quit [Client Quit]
a_chou has joined #zig
<leeward>
Did I hallucinate that there was a change from camelCaseFunctionNames to snake_case_function_names?
<leeward>
Nypsie[m]: It does; I meant not-function insteaf of function. XML_HTTP_Request isn't trivial to get.
<leeward>
instead, even
<Nypsie[m]>
Aaaaah
<Nypsie[m]>
Gotcha
<alexnask[m]>
zls does renaming but I think it has a few bugs
<alexnask[m]>
I have some free time, I will try to improve it and implement packages correctly
<ifreund>
that reminds me, it's been weeks since I last updated my zls
<leeward>
pretty sure I could write a sed script that could rename arbitrary zig symbols without too much effort
<ifreund>
Everything's been working fine so I didn't touch it :P
<Nypsie[m]>
Yeah haven't updated it in forever either, it just works nowadays xD
<leeward>
Yeah, zls is actually what triggered this. It told me my snake case functions didn't follow the style guide so I updated and it didn't change opinion.
marnix has quit [Ping timeout: 240 seconds]
marnix has joined #zig
xackus has joined #zig
marnix has quit [Ping timeout: 256 seconds]
marnix has joined #zig
marnix has quit [Read error: Connection reset by peer]
marnix has joined #zig
wootehfoot has quit [Read error: Connection reset by peer]
<leeward>
Ooh, panic in stage2
<leeward>
I guess I'll have to figure out what caused it...
<leeward>
ahah, found it
<JimRM>
Does anyone know how embeds work under the hood? (Or can they point me in the right direction to find out?) I think something weird is going on.. but it could also be my linkerscript. In one case it seems symbols are pointing to the wrong memory locations when reading embedded data. In another case (mentioned above) I cannot even find the embedded data.
klltkr has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<leeward>
Well, it's not a regression since 0.6
<ifreund>
JimRM: From skimming the compiler source, it looks like it treats the contents of the file just like any other constant string literal
a_chou has joined #zig
<ifreund>
aka a *const [42:0]u8 where 42 is the length
<JimRM>
Do you know how it gets embedded into the final binary?
<ifreund>
just like any other string literal does, there's no special casing for that I see
<ifreund>
so if you don't reference it, it likely won't get embedded
<JimRM>
It is being embedded, just incorrectly
<ifreund>
might help to post code somewhere and elaborate on what exactly is incorrect about it
<Michcioperz>
is the compiler smart enough to figure out which parts are actually referenced?
<JimRM>
The behavior is pretty weird. If I just fill a file with a particular pattern and import that it appears in the final output binary - unchanged. But when I embed something like a zip file, I cannot find any common byte pattern in the output binary
<JimRM>
So 1 1KB file filled with 41414141 will appear as exactly 1kb of 4141 in the final binary
<JimRM>
(Although the address in the symbol table is incorrect)
<ifreund>
hmm, can zip files have null bytes in the middle of the file?
<JimRM>
There is an example - first line is the Symbol table entry for FontEmbed
<JimRM>
The FontEmbed file is completely full of 3131 3131 3131
<JimRM>
You can see there is an offset between 83040 and the beginning of the file's data
<JimRM>
But the data has not been truncated (it is still 1KB of data)
<Michcioperz>
how are you using that embedded data in code?
<JimRM>
I've updated the Gist above
<JimRM>
So x8 is loaded with the address of FontEmbed as it appears in the symbol table. And then offset #28 from there is loaded (which corresponds to Width)
<JimRM>
So it looks like the code being generated is sane
<JimRM>
Just the location of the data OR the value of the symbol is wrong
<Michcioperz>
just random intrusive thought but i wonder if making FontEmbed export const could help
<JimRM>
So that just made the symbol global:
<JimRM>
ffff000000083040 g O .rodata00000008 FontEmbed
<JimRM>
(Same address as before)
xackus has quit [Ping timeout: 258 seconds]
Akuli has quit [Quit: Leaving]
<leeward>
I've successfully embedded compiled executables before. I don't think there are issues with 0 bytes. Maybe it's a regression? What version of Zig are you using?
<JimRM>
0.6.0+749417a1f
<leeward>
It might be worth trying it on 0.6.0.
frett27 has quit [Read error: Connection reset by peer]
<JimRM>
Hmm, I just noticed something interesting - not sure if it was the same before trying 0.6.0
<JimRM>
Yes it was (just checked the gist)
klltkr has joined #zig
<JimRM>
Looks like an indirection thing - if you look at the address: ffff000000083040 it contains the value: 3140 0008 which reversed = 00083140 which is the address at which the data starts
<leeward>
Well that sounds like maybe it's not wrong.
<leeward>
If your machine is little endian, that is.
<JimRM>
Indeed!
<JimRM>
So I guess I need to update this line: var Font: *const PSFFont = @ptrCast(*const PSFFont, &FontEmbed);
<JimRM>
To be a "pointer to a pointer"
<alexnask[m]>
what about `var Font = @ptrCast(*const PSFFont, FontEmbed);`? embedFile returns a pointer to an array
dermetfan has quit [Ping timeout: 260 seconds]
<leeward>
I don't think your stack of u32s will hit it, but you should be aware that packed structs are buggy at the moment.
<JimRM>
@alexnask thanks - I've just tried that and it appears to work
<JimRM>
Now I just need to test it with the "real" data..
<JimRM>
Awesome - it works! I guess when in doubt you should always blame the compiler XD
<leeward>
\o/
<leeward>
To be fair, with Zig the compiler is not all that unlikely to be at fault, relatively speaking.
<JimRM>
I feel the problem I encountered there is something that the compiler should have picked up? ie the additional layer of indirection?
<JimRM>
ie casting a ** to a * (in C parlance) would be a compiler error
<alexnask[m]>
`@ptrCast` can cast from to any pointer
<leeward>
Yep, there it is: *const [X:0]u8
<leeward>
I wonder if @as works there.
<alexnask[m]>
I dont think so, `@ptrCast` or `@bitCast` on the value are the options here
<leeward>
Yeah, it's not "unambiguous and safe."
marnix has quit [Ping timeout: 258 seconds]
a_chou has quit [Ping timeout: 265 seconds]
omglasers2 has quit [Read error: Connection reset by peer]
a_chou has joined #zig
klltkr has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]