06:55 <andrewrk> PC9801, the rust code is calling into dynamically linked (not shown) code but the zig code is 100% all there

06:56 <andrewrk> you probably intend to turn on release builds for both of them

07:02 <wilsonk> lol, I didn't even look at the rust code enough to realize it was calling into dynamically linked code...duh

07:03 <andrewrk> that said, I turned on optimizations and am seeing that the rust code got a lot smaller than the optimized zig code. it looks like the formatting code turned into some vectorized stuff. unclear if this is better or worse than the rust code, would have to execute it to find out

07:05 <andrewrk> and uh, yeah, actually the optimized rust code is calling a (not shown) function for printing, so again it's not a fair comparison

07:08 <andrewrk> PC9801, you can make it fair by using an extern function for printing the values and using an export function instead of main: https://godbolt.org/z/KosohG

09:44 <eleanor-nb> I'm thinking of beefing up the RISC-V inline assembler in stage 2. The conceptual problem I'm running into is: how do we do labels?

09:45 <eleanor-nb> Relative labels can be handled locally, but absolute labels will have to be passed on to later stages of codegen, which will need to be aware of RISC-Vsymbol vagaries.

09:46 <eleanor-nb> Also, incremental compilation will not like that.

09:49 <eleanor-nb> With more thought, I think that absolute labels should not be allowed, and function bindings should only be allowed in `call`, whose implementation we override.

10:07 <eleanor-nb> To make relative jumps work across function calls, it won't be enough to keep track of output address internally -- we'd need to either track exact byte counts of codegen outputs, or get the current output address.

10:21 <eleanor-nb> Here's what I'm thinking:

10:24 <eleanor-nb> (Nvm, still thinking.)

12:32 <Ristovski> Is there anything else besides LTO not being applied across Zig<->C boundary that could theoretically impose a performance regression when mixing Zig and C?

12:37 <scientes> Ristovski, PIC, but otherwise that is basically it. You might want to add a trampoline in some cases to prevent speculative execution.

12:38 <Ristovski> scientes: Ah cool, thanks

12:38 <scientes> PIC is position independent code

12:39 <Ristovski> Yeah I am aware :P

12:56 <PC9801> andrewrk thanks! this makes sense

13:12 <ofelas> does anyone know why: unable to call function with naked calling convention?

13:16 <ifreund> ofelas: you're going to have to give a little more context than that, could you paste the code and error message somewhere?

13:25 <ofelas> https://pastebin.com/jLYpwauB

13:28 <ofelas> error message here https://pastebin.com/ZyWic12V

13:36 <ifreund> um, shouldn't your entry point be the only callconv(.Naked) function?

13:39 <ifreund> pretty sure .Naked means that the function can only be called as an entry point, not from zig code

13:39 <ofelas> I'm blindly following this FreeRTOS Cortex-M3 port calling conventions at the moment, haven't spent to much time analyzing as the "inline" asm fixed the problem

13:40 <daurnimator> no you should be able to call naked from anywhere

13:40 <ofelas> it seems C can call naked functions so I thought Zig could too

13:41 <ifreund> daurnimator: https://github.com/ziglang/zig/blob/55d7c399c136537551359eed6f73a70ac77f7091/test/compile_errors.zig#L3761-L3769

13:41 <ifreund> this suggests otherwise no?

13:43 <daurnimator> ifreund: hmm, looks like we only support calling naked with assembly

13:44 <ifreund> we could definitely use some better docs on calling conventions at least

13:45 <daurnimator> ifreund: a naked function is essentially saying "I'll handle the calling convention myself with assembly 'I will grab my own args from registers/the stack'"

13:45 <daurnimator> "I'll handle it myself" is not inherently incompatible with other calling conventions; but it *might* be

13:45 <daurnimator> i.e. its giving the developer enough rope to hang themselvess

13:45 <ifreund> makes sense

13:47 <daurnimator> _start has to be naked.... because there is no other calling convention for it: you have to do it yourself. but there's no reason you can't write a naked function that does e.g. 20 nops and then the internals of C calling convention

17:21 <scientes> when I showed our _start to people they were a bit scared it wasn't assembly

17:21 <scientes> ofelas, zig can call naked functions

17:22 <scientes> but it doesn't make much sense to do that

17:22 <scientes> as if you are not using standard calling conventions (or fastcc) then you do the call yourself, and not with llvm

17:24 <marler8997_> is there a way to make a function use the C ABI without making it externally visible?

17:24 <BaroqueLarouche> callconv(.C) ?

17:24 <marler8997_> that's it, thanks BaroqueLarouche

18:51 <ifreund> anyone know if there's a non-hacky way to output a library to $PREFIX/lib/security/foo.so with the zig build system?

19:23 <andrewrk> idea being to insert that "security" dir there?

19:24 <andrewrk> is that some kind of standard?

19:32 <ifreund> that's what pam uses

19:32 <ifreund> I'm writing a pam module and using zig of course

19:39 <andrewrk> ifreund, I think you can overwrite Builder.lib_dir field

19:41 <ifreund> on 0.6.0 at least whatever I set gets overwritten in resolveInstallPrefix()

19:42 <ifreund> tried setting the name of the library to "security/foo" as well but there's a check that disallows it as an invalid name

19:54 <andrewrk> alright well sounds like it's not really possible but patch welcome. the build should be fully configurable, shouldn't get in people's way

19:55 <andrewrk> ifreund, is this something that makes sense to be configured by the project, or by the user doing the install?

19:55 <andrewrk> maybe we make a standard option that is always available to override the lib dir?

19:57 <ifreund> configured by the project in this case I believe. pam looks for modules in /lib/security by default and so my project should install to $prefix/lib/security

19:58 <ifreund> users should only need to specify e.g. /usr as the prefix, they shouldn't need to know where pam will search for modules

20:40 <andrewrk> makes sense

20:58 <ifreund> hmm, automatically prefixing my .so file with lib also doesn't fit with the conventions for pam

20:59 <ifreund> maybe I should just be using addObject

21:00 <scientes> ifreund, I remember when systemd wrote a pam module

21:00 <scientes> it was hell

21:00 <ifreund> lol

21:00 <scientes> you have to do all these crazy things

21:00 <ifreund> all mine is going to do is set XDG_RUNTIME_DIR

21:01 <ifreund> I wouldn't need this if I was using (e)logind of course

21:38 <marler8997_> Reading about X and came accross the X "Principles" here, looks like good advice that confirms some of the things I've learned in my years: https://en.wikipedia.org/wiki/X_Window_System#Principles

21:40 <andrewrk> this one goes against zig philosophy: "If you can get 90 percent of the desired effect for 10 percent of the work, use the simpler solution"

21:40 <andrewrk> zig is all about doing extra labor to close that last 10%

21:40 <marler8997_> an interesting detail, of course, it depends on how important that "effect" is

21:41 <marler8997_> when it comes to proper error handling, Zig definitely aims for the 100% approach

21:41 <marler8997_> but then again, I wouldn't say Zig had to add 90% more complexity to handle 100% of errors

21:42 <andrewrk> not assuming memory allocation will succeed would be the main example

21:42 <andrewrk> many programming languages are fundamentally built on the premise that memory is infinite

21:44 <marler8997_> It is infinite from the processor's perspective, because if you ever run out, you get murdered by the OOM...so it's infinite as far as you know :)

21:44 <marler8997_> *process's perspective (not processor)

21:45 <andrewrk> there are many environments where that is not true

21:46 <andrewrk> if you're writing library code, the premise is that it's intended to be reusable code, and therefore behaving correctly on many environments is part of the features the library is providing

21:47 <marler8997_> yeah starting a language with this premise is a much needed thing in my opinion

23:01 <ronsor> hey, does anyone have advice for getting stack traces on UEFI?