ChanServ changed the topic of #zig to: zig programming language | https://ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
cole-h has quit [Ping timeout: 240 seconds]
earnestly has quit [Ping timeout: 260 seconds]
teratorn_ is now known as teratorn
notzmv has quit [Ping timeout: 240 seconds]
trcm has quit [Remote host closed the connection]
notzmv has joined #zig
qbit has quit [Quit: WeeChat 3.1]
aerona has quit [Quit: Leaving]
aerona has joined #zig
klltkr has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
waleee-cl has quit [Quit: Connection closed for inactivity]
notzmv has quit [Ping timeout: 260 seconds]
motersen has quit [Remote host closed the connection]
motersen has joined #zig
SimonNa has joined #zig
leon-p has quit [Quit: leaving]
terinjokes has quit [Quit: ZNC 1.8.1 - https://znc.in]
terinjokes has joined #zig
<andrewrk> ifreund, what terminal application do you use?
notzmv has joined #zig
<andrewrk> enums branch is done
<andrewrk> ended up fixing a bunch of incremental compilation bugs too
jcmdln has quit [Remote host closed the connection]
cole-h has joined #zig
Pixeli has joined #zig
bitmapper has quit [Quit: Connection closed for inactivity]
sord937 has joined #zig
waffle_ethics has quit [Read error: Connection reset by peer]
waffle_ethics has joined #zig
FireFox317 has joined #zig
l1x has joined #zig
<ifreund> andrewrk: I use https://codeberg.org/dnkl/foot
<ifreund> it's wayland only though, won't help if you're still on xfce
<ifreund> looking forward to reading through the enums branch :)
di-wu has joined #zig
teratorn has quit [Read error: Connection reset by peer]
aerona has quit [Quit: Leaving]
cole-h has quit [Ping timeout: 252 seconds]
hspak0 has joined #zig
hspak has quit [Ping timeout: 268 seconds]
hspak0 is now known as hspak
earnestly has joined #zig
Pixeli has quit [Ping timeout: 252 seconds]
FireFox317 has quit [Remote host closed the connection]
FireFox317 has joined #zig
tnorth has joined #zig
johannes_ has joined #zig
johannes_ is now known as kenran
klltkr has joined #zig
m4r35n357 has quit [Ping timeout: 248 seconds]
m4r35n357 has joined #zig
Anzh has quit [Ping timeout: 248 seconds]
kenran has quit [Quit: leaving]
waleee-cl has joined #zig
paulgrmn has joined #zig
retropikzel has quit [Quit: Leaving]
ncon has quit [Ping timeout: 240 seconds]
daurnimator has quit [Ping timeout: 245 seconds]
ncon has joined #zig
daurnimator has joined #zig
bndbsh has joined #zig
Anzh has joined #zig
knebulae has joined #zig
daex_ has joined #zig
daex has quit [Ping timeout: 265 seconds]
Kuraitou_ has joined #zig
<Kuraitou_> https://godbolt.org/z/8Kcq5c1Ez are these bools supposed to be initialized to false or does initializing the containing struct with undefined prevent that?
<g-w1> when you initialize it to undefined, it prevents that. if you want to initilize the struct to a default value, use OuterStruct { .flags = .{} }
<dutchie> you can propagate the default values by defining `const OuterStruct = struct { flags: Flags = .{}, };`
<Kuraitou_> interesting, thanks
<Kuraitou_> is there any other way to correctly initialize flags? this is part of a much larger struct that is initially undefined
<g-w1> undefined_struct_val.flags = .{}
<Kuraitou_> that's what I'm doing, but some of the bools are true for some reason
<Kuraitou_> I was thinking maybe it's something weird with packed structs since it seems to work fine for normal ones
<dutchie> huh, oh yeah. i have heard that packed structs are buggy in stage1
<g-w1> maybe yeah
<Kuraitou_> hm, it seems to work fine for extern structs so I'll just do that for now. Thanks for taking a look.
Snetry has quit [Read error: Connection reset by peer]
Snetry has joined #zig
tnorth has quit [Ping timeout: 258 seconds]
leon-p has joined #zig
leon-p has quit [Client Quit]
leon-p has joined #zig
CodeSpelunker has joined #zig
CodeSpelunker has quit [Client Quit]
dimenus has joined #zig
Akuli has joined #zig
dimenus has quit [Quit: WeeChat 3.1]
dimenus has joined #zig
dimenus has quit [Quit: WeeChat 3.1]
dimenus has joined #zig
fputs has quit [Quit: WeeChat 3.1]
FireFox317_ has joined #zig
FireFox317 has quit [Ping timeout: 260 seconds]
aerona has joined #zig
aerona has quit [Quit: Leaving]
bitmapper has joined #zig
cole-h has joined #zig
jcmdln has joined #zig
retropikzel has joined #zig
aerona has joined #zig
earnestly has quit [Ping timeout: 240 seconds]
FireFox317_ has quit [Ping timeout: 240 seconds]
earnestly has joined #zig
<mikdusan> til an unpatched lld is not going to work for openbsd
<andrewrk> good thing we have our own linker
sord937 has quit [Quit: sord937]
retropikzel has quit [Quit: Leaving]
<mikdusan> seems that lld searches for dylib like `libfoo.so` and openbsd doesn't provide version symlinks to `libfoo.so.1.2` and that's the end of it... which explains segfaulting hello world - no libc and a few others
<mikdusan> i have been rick rolled. Joined stage2-meeting because others lurking early.
<Nypsie> Sorry, jebaited you :)
blueberrypie6 has joined #zig
racoon has quit [Ping timeout: 268 seconds]
Kuraitou_ has quit [Ping timeout: 268 seconds]
blueberrypie has quit [Ping timeout: 268 seconds]
blueberrypie6 is now known as blueberrypie
racoon has joined #zig
FireFox317_ has joined #zig
Akuli has quit [Quit: Leaving]
gpanders has quit [Remote host closed the connection]
FireFox317_ has quit [Ping timeout: 260 seconds]
FireFox317_ has joined #zig
Raito_Bezarius has joined #zig
<Raito_Bezarius> Hello there, I'm trying to debug an UEFI app written in Zig using gdb, but I'm not sure to understand if I can actually use the pdb produced with GDB
<Raito_Bezarius> My host OS is Linux
paulgrmn has quit [Ping timeout: 260 seconds]
gpanders has joined #zig
<andrewrk> hmm idk if there are any uefi people here right now. maybe try #osdev?
FireFox317_ has quit [Ping timeout: 260 seconds]
<Raito_Bezarius> alright, thanks!
gpanders has quit [Remote host closed the connection]
<mikdusan> do we emit pdb from zig when targeting uefi ?
<mikdusan> so looks like freebsd joins linux,macos in llvm12 status with llvm-assertions: `zig build test` passes except for 2 itmes:
<andrewrk> believe so - I think we choose pdb/dwarf depending on object format
<mikdusan> 1. #8429 is fixed if manually applying upstream patch noted in bugzilla
<marler8997> its pe/coff I believe
<mikdusan> 2. #6408 continues to be open issue
<Raito_Bezarius> yeah, it's PE/COFF
<Raito_Bezarius> I wonder how hard would it be to ask for Zig to produce dwarf, andrewrk
<Raito_Bezarius> because it looks like there is no solution to debug using pdb on Linux as I see
<Raito_Bezarius> except writing the pdf2dwarf :D
<Raito_Bezarius> pdb*
<marler8997> out of curiosity, how are you running your efi app? qemu?
<Raito_Bezarius> yes marler8997
<Raito_Bezarius> with OVMF
<marler8997> oh interesting, I've only debugged EFI on hardware with a lauterbach
<mikdusan> we might consider adding flags for debug format and debug version; if we expect people to use native debugger, then at least the version can differ from zig. eg. openbsd 6.8 (latest release) uses dwarf 2 and no system tools are worth a damn against zig's dwarf 4
<Raito_Bezarius> Wow marler8997 :D
<Raito_Bezarius> mikdusan: I'm trying to understand how does it work internally in Zig
<Raito_Bezarius> https://github.com/ziglang/zig/blob/38d8aab4d283efe2f43c7e18411f6df7e1c2d04b/lib/std/build.zig is this the file which controls how does it call llvm?
<mikdusan> Raito_Bezarius: if I understand context: zig doesn't exec an llvm with command-line options for codegen, it calls embedded llvm to codegen and this is where flags like debug format and version are ultimately communicated to llvm
<Raito_Bezarius> alright
<Raito_Bezarius> do you know which file actually pass the flags like debug format & etc?
<mikdusan> I'm curious too... searching... :)
<Raito_Bezarius> Alright, the first who finds out :>
<Raito_Bezarius> wouldn't be this?
<mikdusan> it's going to come before linker stuff
<andrewrk> Raito_Bezarius, that is indeed where zig passes linker flags to LLD
<Raito_Bezarius> but I guess I want to know where debug flags are passed with respect to object files
<andrewrk> object files generated by .zig code?
<Raito_Bezarius> yes
<cepheus> heh i grossly underestimated how much allocation is required to get argv0 on windows
<cepheus> i forgot there's a utf16 conversion involved
<Raito_Bezarius> awesome
<Raito_Bezarius> but is this stage1 actually used in the Zig compiler?
<Raito_Bezarius> I thought Zig was compiled by a Zig compiler?
<mikdusan> stage1 is today
<Raito_Bezarius> and stage1 was only for bootstrapping
<Raito_Bezarius> ah Zig is not yet self-hosting itself?
<mikdusan> stage2 under heavy development right now
<Raito_Bezarius> alright
<Raito_Bezarius> in that case, if I patch this line :>…
<Raito_Bezarius> I will get dwarf I suppose… :>
<andrewrk> Raito_Bezarius, it's worth a try, and if there is a legitimate use case for it, we can expose a flag
<Raito_Bezarius> okay, will hack quickly a patch and try it on my project
mikdusan has quit [Quit: WeeChat 3.0.1]
<Raito_Bezarius> how long is stage1.zig to build using zig0 ?
<Raito_Bezarius> as there looks like to be no output on the build process
<Raito_Bezarius> though I'm seeing a core being fully used
<Raito_Bezarius> (i7 8th gen)
<Raito_Bezarius> alright, I was not patient enough, that took 10 good minutes
<Raito_Bezarius> that worked
<Raito_Bezarius> it produced dwarf in the EFI binary
<Raito_Bezarius> now to see if I can actually get symbols
mikdusan has joined #zig
<Raito_Bezarius> can I run in build.zig something like objcopy to strip sections?
<g-w1> b.addSystemCommand
<Raito_Bezarius> thanks!
<cepheus> hmm it only takes me about a minute to build stage1 from sources
<Raito_Bezarius> guess that spectre & meltdown mitigations hit hard
<Raito_Bezarius> <:
<mikdusan> not enough mem and swapping? which linker (gnu? is it in lto-mode?) and linking against llvm debug all cause headturning jumps in build time
<Raito_Bezarius> 32G of RAM
<Raito_Bezarius> though swap looks a bit high
<Raito_Bezarius> I guess it was lld for the linker but unsure
<Raito_Bezarius> LLVM11
<mikdusan> lld speed is usually fine
<mikdusan> building zig1.o needs about 7 GB mem so good there
<Raito_Bezarius> I was already close to 16-18GB RAM taken
<Raito_Bezarius> I will try to reproduce anyway
<mikdusan> linking against llvm static libs or dylibs ? I don't ever use dylibs
<Raito_Bezarius> I built it using a Nix expr
<Raito_Bezarius> basically, https://shared.lahfa.xyz/354sjjq/zig.nix
<Raito_Bezarius> (it's more a 0.8.0 rather than a 0.7.1 but anyway)
<g-w1> Raito_Bezarius: see the nix expr in the wiki
<Raito_Bezarius> hm, which wiki g-w1 ?
<Raito_Bezarius> nixos' one or zig?
<g-w1> zig wiki github
<Raito_Bezarius> makes sense
<Raito_Bezarius> but I just wanted a quick "release" compiler to use it with the project rather than developing on Zig
<Raito_Bezarius> I don't plan to develop both at the same time
<Raito_Bezarius> (hopefully)
<mikdusan> what does the unwrapped part of `llvmPackages_11.clang-unwrapped` mean?
<Raito_Bezarius> I guess that unwrapped is just the binary
<Raito_Bezarius> rather than wrapped is the whole CC/libcxx/extra packages, etc.
<Raito_Bezarius> an Clang environment
<Raito_Bezarius> and the line just after is about wrapCCWith { cc = clang-unwrapped; … };
<mikdusan> ah.. canonical :)
<g-w1> Raito_Bezarius: ahh a release built takes much longer than a debug one which takes 1m
<Raito_Bezarius> ah alright!
<Raito_Bezarius> makes sense then :)
<g-w1> i would like a way to do release c++ with debug zig
<Raito_Bezarius> does someone understand why when I'm loading symbols, I get now: Remote target doesn't support qGetTIBAddr packet ?
<Raito_Bezarius> when attaching gdb through remote debugging
<Raito_Bezarius> (I get two files, an EFI without debug sections and an EFI with debug symbols, which I relocate using add-symbol-file and reading the UEFI image_base at runtime)
<mikdusan> what is file ext of 2nd file?
<Raito_Bezarius> .efi
<Raito_Bezarius> it's computed using objcopy on the "right" sections
<Raito_Bezarius> all debug_*
<Raito_Bezarius> do you think gdb actually care about file exts and does not check the real content?
<mikdusan> hmm... see if you can debug with one file namd .efi and other .debug ? I recall something like that
<mikdusan> s/namd/named/
<Raito_Bezarius> let's give it a try
<Raito_Bezarius> same thing
<Raito_Bezarius> but maybe the fact this is still a PE file with debug sections
<Raito_Bezarius> is the reason why it's not working
<mikdusan> does this page give any hints? https://wiki.osdev.org/Debugging_UEFI_applications_with_GDB
<Raito_Bezarius> this is the exact page I was trying to follow
<mikdusan> nice :)
<Raito_Bezarius> but I think the main difference is that they have actual ELF images
<Raito_Bezarius> and I am using PE images
<Raito_Bezarius> that's okay for EFI binary
<Raito_Bezarius> but maybe for the debug symbols…
<mikdusan> what is the -target you are using so I can create a simple .o
<Raito_Bezarius> do you mean my targets in the build.zig ?
<mikdusan> yes
<Raito_Bezarius> at least it's complete this way :)
<Raito_Bezarius> .cpu_arch = .x86_64 & .os_tag = .uefi
<Raito_Bezarius> I have noticed I forgot to keep .text, .data, .reloc for .debug
<Raito_Bezarius> but that didn't change anything
<Raito_Bezarius> lldb seems to be able to read the symbols without any splitting
<Raito_Bezarius> seeing Zig code in lldb symbols dump warmed my heart
bndbsh has quit [Quit: Connection closed for inactivity]
<mikdusan> when I target x86_64-uefi with trival .zig and build-obj it comes out elf, not pe
<Raito_Bezarius> which version of Zig?
<mikdusan> master
<Raito_Bezarius> I was using 0.7.1
<Raito_Bezarius> and hm
<Raito_Bezarius> I don't understand
<Raito_Bezarius> the fork is derived from master
<Raito_Bezarius> so I should also get ELF
<Raito_Bezarius> but I have
<Raito_Bezarius> build/EFI/BOOT/BootX64.efi: PE32+ executable (EFI application) x86-64, for MS Windows
<Raito_Bezarius> ah
<Raito_Bezarius> but you used build-obj