<andrewrk>
supposedly linux ignores the stack size from the ELF file and uses a hard coded value, but in this case we can simply mmap more stack memory upon startup to fix it.
<andrewrk>
if the kernel doesn't want to perform its duties, we can clean up its mess
<shachaf>
whoa, I had no idea. I'll look at what that does to the ELF file when I get back to my computer.
<shachaf>
The Linux behavior is quite odd, I remember -- it maps more stack memory (up to the rlimit?) when you reach the end of the stack. No idea why they do that.
<shachaf>
It would be nice if you could also get stack information when called from a C function, but I guess statically bounding it is the best you can do.
moo has quit [Read error: Connection reset by peer]
<shachaf>
Oh, --stack is a mingw linker option. Maybe this is just a PE thing.
<shachaf>
It looks like ELF files don't have a way to specify this at all?
<shachaf>
Oh, GNU_STACK nominally lets you specify it. But Linux ignores it like you said.
nathanf has joined #zig
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 258 seconds]
waleee-cl has quit [Quit: Connection closed for inactivity]
laaron has quit [Remote host closed the connection]
laaron has joined #zig
laaron has quit [Remote host closed the connection]
laaron has joined #zig
marijnfs__ has joined #zig
marijnfs_ has quit [Ping timeout: 272 seconds]
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 246 seconds]
<daurnimator>
if you use `usingnamespace` does it import method? and what happens to where those methods take a @This()?
<daurnimator>
==> I'm trying to figure out how to share some methods between two structures without writing them out twice
<mikdusan>
afaict `usingnamespace` and even manual `const myfunc = Other.myfunc;` does work for methods .... well the latter makes the fn lookup there, but invoking it like a non-object func generates expected mismatched error type
<mikdusan>
err.. typo. **doesn't** work.
<marler8997>
it looks like, in order to get zig to behave like a normal C compiler, we just have to add the arguments for libc....does that sound right?
<mikdusan>
daurnimator: also seems if using comptime to create a new fn and adding to struct, the `object.method()` syntax doesn't work; ie: it's only recognized for regular fn call syntax
curtisf has quit [Remote host closed the connection]
<marler8997>
hmmmm, looks like it's more complex, zig is building libc dynamically
nathanf has quit [Remote host closed the connection]
laaron has quit [Remote host closed the connection]
laaron has joined #zig
dewf has joined #zig
<marler8997>
how would I do a "zig build-obj --c-source foo.c"? It can't find the C header files unless I add --library c, but then if I add that then it tries to link libc into the object file
laaron has quit [Remote host closed the connection]
laaron has joined #zig
laaron has quit [Remote host closed the connection]
laaron has joined #zig
porky11 has quit [Read error: Connection timed out]
porky11 has joined #zig
* daurnimator
waves
laaron has quit [Remote host closed the connection]
laaron has joined #zig
<daurnimator>
what do we do for older kernels that don't have new syscalls?
<daurnimator>
like.... should we check for ENOSYS and try other options?
<daurnimator>
e.g. I have code that calls pwritev2. Should I check for ENOSYS and *only if* the flags argument is 0, try pwritev instead?
kristoff_it has joined #zig
porky11 has quit [Quit: Leaving]
<Tetralux>
Can you do what you want without the syscall?
<Tetralux>
My first thought would be to avoid the need for syscalls that I don't absolutely need, instead of calling multiple different ones.
<Tetralux>
If you have to have it, I'd probably just use the most commonly available one.
<Tetralux>
If the v1 syscall is on more systems, and it does not suffer from security problems, then I'd try to get away with that one.
return0e_ has joined #zig
return0e has quit [Ping timeout: 246 seconds]
<daurnimator>
Tetralux: the new syscall is much faster. you can do it on older systems but it requires multiple syscalls and a lock
kristoff_it has quit [Ping timeout: 272 seconds]
<Tetralux>
Ahhh. I see. One of those.
<Tetralux>
I'd check ENOSYS and fallback for the rest of the program probably, yeah.
<Tetralux>
At least, I would if I _really_ need to support older kernels.
<Tetralux>
I don't know what the availablity of that syscall is though.
<daurnimator>
4.6+ I think but the flags I want are 4.14+
<Tetralux>
The flags came in before the call that takes them?
<Tetralux>
They apply to multiple things?
<daurnimator>
no the call was in 4.6+; then they added more flags in 4.14
<daurnimator>
and yes the flags also apply to multiple things...
<daurnimator>
According to the zig support table we target Linux 3.16+
<daurnimator>
so I need some solution for older kernels...
laaron has quit [Remote host closed the connection]
<Tetralux>
Man I'm tired
<Tetralux>
I just realised that 14 > 6.
<Tetralux>
I was reading it as 4.6 and 4.1.6 xD
<Tetralux>
I'm a moron.
<Tetralux>
4.1.4*
laaron has joined #zig
<daurnimator>
There's also the question of how to check for flag support...
<daurnimator>
kernels >4.6 <4.14 will just return EINVAL..... but if I do it with actual user input then I won't know if the EINVAL is from them or me...
<daurnimator>
So do I check for syscall support in an .init() method somehow?
<Tetralux>
Hmmmm.
<Tetralux>
I can't think of anything better xD
<Tetralux>
Perhaps there should be a syscall you can make where you can query what is available.
<Tetralux>
And what parameters it takes.
<Tetralux>
That'd be handy.
<daurnimator>
Maybe a global variable "kernel version" or something? they we could use it for more than just this one case?
<Tetralux>
Maybe.
<Tetralux>
Maybe there's a way to abstract away the syscall, such that you basically just say "Hey Kernel, I want [this] behavior. Here's the args for it. Can you figure it out please and tell me how you did?"
<daurnimator>
uh, no. that's not how syscalls work :p
<Tetralux>
I realise that isn't how it works - I'm saying it may help to have a way to have the kernel figure it out and not you. xD
<daurnimator>
how would the kernel "figure it out"
<Tetralux>
Essentially, you ask for new syscall, the kernel realises it doesn't have it, but you passed the MAKE_IT_WORK flag, so it performs the old, slower way of doing it with the info you gave it.
<Tetralux>
(and tells you that it did that.)
<daurnimator>
but that doesn't exist... because the kernel is old and it doesn't know what $NEW_THING is
<Tetralux>
True. Hmm.
<daurnimator>
in such cases its often up to libc to make it work on old kernels... and in case of zig that means our std lib. so.... we should have an answer :P
<Tetralux>
I just get the feeling that there's a more imaginative, better way to solve this problem.
<Tetralux>
But yes - there should definitely be an answer to it.
<Tetralux>
Even though you might expect only a higher level kernel stdlib interface to do that kind of thing, it would still be handy for the people actually using the syscalls to have a way to determine these things.
<Tetralux>
Does pwritev effectively the same as writing a rope string to a fd?
<Tetralux>
Is that essentially what it does?
<Tetralux>
If so, that's kinda interesting.
<daurnimator>
yeah. and you also get to provide the offset (so you don't need to e.g. seek).
<daurnimator>
then RWF_NOWAIT lets you know when a read/write can't be done instantly and should be sent to a thread pool
<daurnimator>
RWF_APPEND lets you have per-write O_APPEND
<Tetralux>
It appends the rope string in the same way as if it was one single buffer as in write?
<daurnimator>
yes
<Tetralux>
That's handy xD
wootehfoot has joined #zig
SimonNa has joined #zig
fsateler has quit [Ping timeout: 245 seconds]
fsateler has joined #zig
laaron has quit [Remote host closed the connection]
laaron has joined #zig
<marler8997>
Looks like an empty zig file built with "zig build-obj" comes out to 518K? touch foo.zig && zig build-obj foo.zig
avoidr_ has joined #zig
avoidr has quit [Ping timeout: 244 seconds]
laaron has quit [Remote host closed the connection]
laaron has joined #zig
wootehfoot has quit [Read error: Connection reset by peer]
dimenus has joined #zig
avoidr_ has quit [Quit: leaving]
avoidr has joined #zig
companion_cube has quit [Ping timeout: 268 seconds]
Ichorio has joined #zig
kristoff_it has joined #zig
companion_cube has joined #zig
kristoff_it has quit [Ping timeout: 245 seconds]
curtisf has joined #zig
<gonz_>
marler8997: Are you including `--strip` & using `strip` after on the executable?
<gonz_>
AFAIK that's primarily how you'd get the size down
<curtisf>
`literals` is defined a s a global: `var literals: [100]Literal = [_]Literal{undefined} ** 100;` and all of the others are plain integers, so not sure how this should be segfaulting
<curtisf>
I'm guessing related to location result branch since this was working before I updated?
<fengb>
Try creating a temporary const and copying it over? That should work around copy elision
<fengb>
And if that’s the case, probably log a bug to track it
kristoff_it has joined #zig
<curtisf>
Ah, that does fix it, thanks
kristoff_it has quit [Ping timeout: 246 seconds]
companion_cube has quit [Ping timeout: 246 seconds]
kristoff_it has joined #zig
companion_cube has joined #zig
kristoff_it has quit [Ping timeout: 245 seconds]
curtisf has quit [Remote host closed the connection]
companion_cube has quit [Ping timeout: 246 seconds]
<gonz_>
Are full optimizations available to zig when there is a comptime struct of function pointers being passed to a function for use?
<gonz_>
Since it forces all the functions to be known at compile time it should be as easy as compiling them into the function that uses them without overhead, right?
<mq32>
i think if the parameter is comptime, the evaluation should be fast
<mq32>
but i don't know
<Tetralux>
They mean "do these fn ptrs turn into static function calls because the array is comptime" IIUC.
<Tetralux>
I would be sad if that was not the case, however I do not know if it actually does do that.
<gonz_>
I find it to be a very nice pattern; specifying an interface that is passed to a more generic function but still hopefully preserving the same performance characteristics of a specialized function using those functions inline
<gonz_>
I can't come up with any reason it shouldn't be able to, but the question is whether or not we are doing it atm.
<mq32>
brainfart: stuff like that should go into the language specification
<mq32>
"if values are passed comptime, it's guaranteed that …"
companion_cube has joined #zig
shritesh has joined #zig
shritesh has quit [Client Quit]
curtisf has joined #zig
companion_cube has quit [Ping timeout: 245 seconds]
companion_cube has joined #zig
companion_cube has quit [Ping timeout: 244 seconds]
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 268 seconds]
laaron has quit [Remote host closed the connection]
laaron has joined #zig
companion_cube has joined #zig
<gonz_>
Yeah, it seems to be generating a call near relative when you specify `comptime` on the interface struct
<gonz_>
(`e8 ...`)
<gonz_>
Whereas otherwise it'll do `ff ...`
<gonz_>
On amd64, that is
companion_cube has quit [Ping timeout: 244 seconds]
kristoff_it has joined #zig
kristoff_it has quit [Ping timeout: 248 seconds]
companion_cube has joined #zig
dingenskirchen has joined #zig
curtisf has quit [Remote host closed the connection]
kristoff_it has joined #zig
companion_cube has quit [Ping timeout: 246 seconds]
kristoff_it has quit [Ping timeout: 246 seconds]
companion_cube has joined #zig
companion_cube has quit [Ping timeout: 268 seconds]
companion_cube has joined #zig
companion_cube has quit [Ping timeout: 245 seconds]
companion_cube has joined #zig
<gonz_>
Has anyone used Binary Ninja with zig executables?
<gonz_>
It doesn't automatically manage to demangle names, it seems
<gonz_>
They say they're reading PDB files automatically from the same directory as the executable too
<gonz_>
I don't really know what to expect since it's the first time I use it overall
kristoff_it has joined #zig
ltriant has joined #zig
kristoff_it has quit [Ping timeout: 272 seconds]
tgschultz has quit [Read error: Connection reset by peer]
tgschultz has joined #zig
<Sahnvour>
gonz_: I thought zig symbols weren't mangled
<gonz_>
I don't even know what BinaryNinja is doing. It's like they're purposefully *not* reading the labels
<gonz_>
They're right there in the file
<gonz_>
I don't know how they can even fail in reading the names at that point