tag:blogger.com,1999:blog-5246987755651065286.post7086009314225817800..comments2024-02-22T16:15:42.388-08:00Comments on cbloom rants: 12-31-13 - Statically Linked DLLcbloomhttp://www.blogger.com/profile/10714564834899413045noreply@blogger.comBlogger9125tag:blogger.com,1999:blog-5246987755651065286.post-59179032692669165502014-01-08T01:17:57.320-08:002014-01-08T01:17:57.320-08:00Agreed.
I looked a bit at doing this myself (writ...Agreed.<br /><br />I looked a bit at doing this myself (writing a "linker" that would put symbols in a namespace) but I think my conclusion was that C++-linking model was too hard. Lots of stuff that needs to happen and be put in right place etc. And by pulling in CRT all specials features are needed. Pure C would work, but that is not interesting if all dependencies need to be pure C as well.<br /><br />I'm toying with the idea of using link.exe with some settings to produce a DLL that is then converted back into a library. I'm thinking that PIC (position independent code) might be used etc.<br /><br />That way LTCG (link time code generation) would work and link.exe would do everything required. One drawback (apart from it being somewhat involved to do) would be that all the "exported" functions would probably end up in one segment, requiring all of them to end up in the final EXE-file. A second pass of LTCG might remove them, but not sure. Also stuff like PIC might result in subpar performance.<br /><br />Things that are hardish are global constructors, exception unwind etc.<br /><br />I think I've accepted DLL-files for now...breakinhttps://www.blogger.com/profile/08000288016642911017noreply@blogger.comtag:blogger.com,1999:blog-5246987755651065286.post-14593400294758966412014-01-07T09:24:44.123-08:002014-01-07T09:24:44.123-08:00Yeah, we've rambled about this a bit before.
...Yeah, we've rambled about this a bit before.<br /><br />IMO every extern being public is one of the biggest disasters of C and in practice makes all C libraries totally unpredictable and dangerous. You can just never know when linking two libraries together will cause them to change behavior.<br /><br />Many of the gcc platforms have the ability to specify private/public linkage on libraries. But it needs to be cleaned up and made official as some kind of C "packages".<br /><br />We also need a big change to the CRT. Particularly malloc and stdio need to be built on top of pluggable function pointers, so that the client can explicitly decide whether heaps are shared between packages or not, etc.<br /><br />There should be two clearly separate parts of the CRT. The pure code part (strcmp) that is linked in to your package and does not create any external dependencies, and the system-dependent part (the plugins for malloc/stdio). That would very easily eliminate the whole problem of "I built with elibc 4.3.20.shit.fuck and the client only has libce 20.3.4.foobar"<br /><br />All of this is so trivial and would make a huge difference to the usability of C.<br />cbloomhttps://www.blogger.com/profile/10714564834899413045noreply@blogger.comtag:blogger.com,1999:blog-5246987755651065286.post-22663633138894436612014-01-07T00:04:22.547-08:002014-01-07T00:04:22.547-08:00No comment on your idea, but it would be nice if l...No comment on your idea, but it would be nice if link.exe could "pre-link" a library. That is; pull in all external dependencies and put them in a symbol "namespace".<br /><br />That would truly be a statically linked DLL. I think you've written about it before, but I could be mistaken.<br /><br />Might lead to symbols from CRT being duplicated, and each "module" would have their own heap (same restrictions as in a DLL where you might use the wrong CRT). Basically a DLL with static CRT packaged as a library. Might not work perfectly if the external dependencies depend on DLL's other than kernel32.dll etc, but otherwise it should be safe.<br /><br />This is a fairly windows-only solutions. I'm not sure that you can statically link everything on linux/osx in the same manner..?breakinhttps://www.blogger.com/profile/08000288016642911017noreply@blogger.comtag:blogger.com,1999:blog-5246987755651065286.post-53108855702098275282014-01-02T02:31:18.368-08:002014-01-02T02:31:18.368-08:00If you load the DLL manually from memory, how are ...If you load the DLL manually from memory, how are people supposed to get symbols in the debugger?<br /><br />Cure worse than the disease if you ask me.Fabian 'ryg' Giesenhttps://www.blogger.com/profile/13685994980026854143noreply@blogger.comtag:blogger.com,1999:blog-5246987755651065286.post-14078406569841381772014-01-01T03:09:28.575-08:002014-01-01T03:09:28.575-08:00How about /Zl (Z + lowercase L) to compile static ...How about /Zl (Z + lowercase L) to compile static libs? http://msdn.microsoft.com/en-us/library/f1tbxcxh.aspx<br />We are shipping static libs compiled with /Zl and customers are linking it with whatever runtime they use - release, release dll, debug, debug dll. Of course, that works only if you don't use STL in API. We have only simply C API.<br />Mārtiņš Možeikohttps://www.blogger.com/profile/08184659145643004228noreply@blogger.comtag:blogger.com,1999:blog-5246987755651065286.post-32383961590792503102013-12-31T14:24:23.483-08:002013-12-31T14:24:23.483-08:00@Jeff
Google suggests that the "recommended&...@Jeff<br /><br />Google suggests that the "recommended" way to create writable + executable memory on SELinux is to use two mappings, one writable, one executable. Since the two mappings need to share the same memory, you need to give them a name in the filesystem.<br /><br />See: http://www.akkadia.org/drepper/selinux-mem.html<br /><br />It looks really ugly to me, particularly because if the filesystem you use for the temp file is mounted noexec, then the whole thing fails, so you need to try multiple locations to find somewhere that you can create an executable file.<br /><br />There's some code in libffi to do it:<br /><br />https://github.com/atgreen/libffi/blob/master/src/closures.c<br /><br />(disclaimer: I haven't tested any of this myself)johnbhttps://www.blogger.com/profile/15875751919051082588noreply@blogger.comtag:blogger.com,1999:blog-5246987755651065286.post-86336767305816198572013-12-31T14:02:13.681-08:002013-12-31T14:02:13.681-08:00Oh yeah, you remind me that libc version problems ...Oh yeah, you remind me that libc version problems on Linux/gcc is a comparably disastrous problem, if not worse.cbloomhttps://www.blogger.com/profile/10714564834899413045noreply@blogger.comtag:blogger.com,1999:blog-5246987755651065286.post-3833187433050019982013-12-31T12:30:29.069-08:002013-12-31T12:30:29.069-08:00The problem is that it's becoming increasingly...The problem is that it's becoming increasingly hard to allocate memory that you write to that can later have the execute bit on. On SE Linux, I've never found a way.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5246987755651065286.post-18038121581134495262013-12-31T12:29:19.862-08:002013-12-31T12:29:19.862-08:00We have that already - RADDLL is in shared. You ca...We have that already - RADDLL is in shared. You can load a Win 32-bit DLL from memory on Win, Mac and Linux. I need to make a 64-bit version, though.Anonymousnoreply@blogger.com