<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
<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>
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>
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