ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
<pupppp>
Doesn't look like it's the best way to show patches.
hasen_judy has joined #zig
<pupppp>
Trying to figure out how to print something from inside lld. There is message(const Twine &Msg) in deps/lld/COFF/error.cpp, but not sure what Twine is.
<pupppp>
something multithreading related.
<pupppp>
I have a guess on how to rearrange sections, just need to rearrange OutputSections inside deps/lld/COFF/MapFile.cpp
<pupppp>
i meant, inside deps/lld/COFF/Writer.cpp
<pupppp>
std::iter_swap(OutputSections[0], CodeSection) didn't work it seems. It needs iterators, I passed just values themselves.
hasen_judy has quit [Remote host closed the connection]
<ltr_>
strip is giving me a segfault
<ltr_>
on ubuntu
<ltr_>
llvm 5.0.1
<pupppp>
--strip or strip?
<pupppp>
--strip gives segfaults for now, haven't tried strip.
<dimenus>
andrewrk: looking for a little clarity on your feedback, are you against global/static data in general?
<dimenus>
or just static initializers?
<andrewrk>
just code that runs before main()
<andrewrk>
e.g. heap allocations
<andrewrk>
so for example you could lazily initialize the data, or explicitly initialize it with a call in main()
<andrewrk>
but I think the state belongs in the CodeGen struct, not in os.cpp
<andrewrk>
you did most of the work already though, and this is just kind of my preference, so I'd be happy to take it from here if you want
<dimenus>
ok, I'll just store it as two bufs on CodeGen though
<dimenus>
**then
<andrewrk>
works for me
<andrewrk>
and you would pass them into the os function
<andrewrk>
because os.hpp shouldn't know about CodeGen
<dimenus>
my intuition was to hide it since I'm saving the lib / include paths which are what the rest of the code is interested in
<dimenus>
so I tried to hide it
<dimenus>
but I understand the concern about static initializers
<andrewrk>
yeah it makes sense what you did. I think we want to "refresh" the information between compilation invocations though
<andrewrk>
e.g. if you created a CodeGen and did a compilation, then sleep(999) while you install/uninstall MSVC, then create another CodeGen and do another compilation
<andrewrk>
zig should do the right thing
<dimenus>
wait, you don't want os.hpp to konw about codegen?
<dimenus>
how would that work then
<andrewrk>
you would pass the state into the functions that need it
<dimenus>
hmm, so then the codegen itself should absolutely have a reference to the sdk path
<andrewrk>
yes
<andrewrk>
I think it makes sense to expose the part where you explicitly want to check for an SDK. you might want to do it more than once in the process's lifetime
<dimenus>
i'm just making sure I understand this right, the os functions would need access to CodeGen
<dimenus>
which would mean os.hpp now needs all_types.hpp
<dimenus>
i thought I read above that you wanted to avoid that
<dimenus>
yep, will mark that up later today then.
<dimenus>
thanks
<andrewrk>
awesome. this is a huge contribution to zig
<andrewrk>
dimenus, and congratulations on your first pull request
hasen_judy has quit [Ping timeout: 252 seconds]
<dimenus>
thanks!
<dimenus>
It looks like your code for linking with the mingw CRT is commented out, I might tackle that one as well
<andrewrk>
dimenus, that would be neat. I was waiting until llvm 6 comes out, since they added a mingw driver to LLD
<andrewrk>
it might work even before that though? I'm not sure
<andrewrk>
btw, LLD 6 also makes debugging zig programs work in MSVC
<dimenus>
maybe i should be using that backend then
<dimenus>
:D
<dimenus>
which branch are you cloning, stable?
hasen_judy has joined #zig
<andrewrk>
master branch is the main, supported branch
<andrewrk>
everything else is work-in-progress
<andrewrk>
I'll keep the llvm6 branch up to date with LLVM master branch until 6 is released, then I'll merge it into master
<andrewrk>
but there's still an assert triggering in the llvm6 branch, which I'll look into fixing today
hasen_judy has quit [Ping timeout: 252 seconds]
<dimenus>
i'm triggering out what's causing the hang in mingw
<dimenus>
it's something in codegen_link
<dimenus>
**triggering = trying
<andrewrk>
dimenus, is the hang on exit?
<andrewrk>
I think pupppp's workaround is reasonable; there's no reason to call destructors in DLLs anyway
<dimenus>
msvc doesn't hang though
<dimenus>
andrewrk: yes, it is. Also, you changed your mind on the feedback?
<dimenus>
Just using strings on the CodeGen struct now
<andrewrk>
I didn't change my mind, I think I'm just not communicating well
<andrewrk>
I don't care if they are strings or a struct, but the state needs to be in CodeGen, and the same state used for the same CodeGen unit
<dimenus>
ok, so find_windows_sdk should really return early if its already populated
<dimenus>
to ensure consistency
<andrewrk>
find_windows_sdk should always do work, no caching. in the logic outside of os.cpp, the code should use CodeGen to cache the value and not call find_windows_sdk if it is already populated
<dimenus>
thumbsup.png
<pupppp>
my workaround is terrible, I should recompile dll and make it close properly. Doubt I'll understand anything there though. Also it's not quite mine.
<dimenus>
can you send me the link to the workaround pupppp
<andrewrk>
dimenus, move main to main2, have main call main2, and call os.exit(return_code), implement os_exit as _exit(code) for POSIX and TerminateProcess(GetCurrentProcess(), code) for windows
<andrewrk>
e.g. don't let main return to libc
<andrewrk>
sorry, os_exit (defined in os.hpp/os.cpp) not os.exit
<pupppp>
it's honestly utterly terrible. It's hiding a problem instead of solving it.
<andrewrk>
is it though?
<andrewrk>
what can possibly happen in a DLL that we want to happen on exit?
<pupppp>
all other dll work properly without it. Need to fix dll.
<andrewrk>
maybe put fflush(stderr); fflush(stdout); after calling main2
<pupppp>
need to read system internals to find out
<andrewrk>
I'll tell you the answer: it's nothing. any code that is in a DLL destructor is a bug
<andrewrk>
if that DLL depends on the destructor being run, then it will behave incorrectly if the system loses power or is abruptly killed by task manager
<andrewrk>
the OS does the important stuff automatically: cleaning up memory, closing file descriptors, ending network connections
<pupppp>
fixing llvm.dll have extra benefits like, making distribution smaller? It probably generates code for 15 different processors, you rarely need it all.
<pupppp>
probably unrealistic.
<dimenus>
linking on mingw takes so long
<dimenus>
sooooo long
<pupppp>
dimenus, fixed that in the same issue
<pupppp>
not really fixed, just compiled lld separately, as dll
<andrewrk>
pupppp, it's important to zig to have cross compilation work out of the box. the cost is not high. windows zig distribution is 19 MB, no big deal
<pupppp>
i like tiny c compiler so much. A working c compiler in 400 lines of code.
<pupppp>
code is low quality, but it works
<dimenus>
andrewrk: hopefully that wraps up the last of the issues
<pupppp>
it eventually crumbled under it's weight though
<ltr_>
does go depends on lld?, it seems to me that they implemented their own linkers for every os
<andrewrk>
ltr_, yes they implemented their own linkers
<andrewrk>
we might have to do the same for MACH-O since LLD has poor support for that
<ltr_>
when i was researching for the patch for mach-o, i saw that their linker for osx is really simplier than lld, and it just work
<andrewrk>
dimenus, looks good, I think the only problem left is the build failure on POSIX