Re: [Tinycc-devel] Question about in-memory compilation target
Sean Conner wrote in <20240208102201.gb22...@brevard.conman.org>: |It was thus said that the Great grischka via Tinycc-devel once stated: |> On 07.02.2024 09:38, Eric Raible wrote: ... | Lua contains a way to set a custom realloc() function (via |lua_newstate()), thus allowing someone who is embedding Lua into an |application to use a custom allocator, or even just restrict the amount of |memory Lua can use. There is also a function in Lua to obtain the \ |allocator |function Lua is currently using (via lua_getallocf()). I think the possibility to replace an allocator is a good thing. I was frustrated that one of the first things of the libressl fork was to remove that possibility (i had found lots of problems in the MUA i took maintainership of by hooking that thing), and such. I loved the old libraries, graphics and such, which per-se supported hooking their allocators. Then again, today, so many pieces of cake install on-fork, etc, handlers, use so-called sophisticated linker techniques, that whatever you do you have a bunch of things using either the standard allocator, or their very own, non-hookable thing, that you are total at odds, anyhow. As a nice counter-example, just this/last week FreeBSD introduced the split of POSIX+ systemcalls into a libsys library, and out of the standard C library. But this is a tiny drop, and non-portable it is of course, too. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Question about in-memory compilation target
It was thus said that the Great grischka via Tinycc-devel once stated: > On 07.02.2024 09:38, Eric Raible wrote: > > The alternative is having to know about messy system-dependent details, > > which seems very much against the spirit of the (lovely) libtcc API. > > Well, if it's "lovely" then maybe because it's still small and > fairly easily to read. > > In any case, there is always a conflict between simplicity > and any new addition, even if they may come very convenient > in some case. > > Maybe you (or other people) could tell a bit more why now that > tcc_set_realloc() > can be useful enough that tcc should have it, more exactly? > > And if so, why then do we need > tcc_get_realloc() > too? Is that just an exercise about "setters" and "getters" or > is it really useful? Lua contains a way to set a custom realloc() function (via lua_newstate()), thus allowing someone who is embedding Lua into an application to use a custom allocator, or even just restrict the amount of memory Lua can use. There is also a function in Lua to obtain the allocator function Lua is currently using (via lua_getallocf()). I checked, and back in 2012 when I created a Lua module around TCC [1] there was no way to set the TCC allocator to use the allocator from Lua. If someone went to the trouble of setting up a custom allocator for Lua, then any Lua module that might allocate memory should probably use it. I'll admit, my use case of TCC is a bit unusual, and my request to make tcc_relocate_ex() public after you made it private for some reason was met with over a month long argument about it. -spc [1] https://github.com/spc476/lua-conmanorg/blob/master/src/tcc.c ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Question about in-memory compilation target
On 07.02.2024 09:38, Eric Raible wrote: > The alternative is having to know about messy system-dependent details, > which seems very much against the spirit of the (lovely) libtcc API. Well, if it's "lovely" then maybe because it's still small and fairly easily to read. In any case, there is always a conflict between simplicity and any new addition, even if they may come very convenient in some case. Maybe you (or other people) could tell a bit more why now that tcc_set_realloc() can be useful enough that tcc should have it, more exactly? And if so, why then do we need tcc_get_realloc() too? Is that just an exercise about "setters" and "getters" or is it really useful? While at it, why do we need these ones tcc_get_error_func() tcc_get_error_opaque() seen that people should be able to remember what they have set, in their own code too? As to "tcc_relocate()" and "tcc_unprotect(mem)", that would probably good to have. On the other hand it's already built-in into tcc_delete(). Maybe it is not worth to keep up that option to compile into memory provided by the user at all. If we'd tweak the state data a bit to keep only the minimum required instead, for example with "tcc -run tcc.c -v" code size: - 421047 bytes state data sizes: - 1088 bytes : struct TCCState itself (on i386) - 5649 bytes : public symbols (= 160 public symbols ~= 35 bytes each) - 546 bytes : file names, include paths, defines, etc. - 7283 bytes total Which means that in this case the state data is less than 2% of the total memory usage. Then, instead of adding a new API to support the "run without state" option better (as you suggest), we could just as well remove that option entirely, and have a simpler and more "lovely" API then ... What do you think? -- grischka When using void *mem = malloc(tcc_relocate(s, NULL)); tcc_relocate(s, mem); wouldn't it make sense for tcc to export a function to safely restore the pages to R/W in a platform independent way? I haven't been able to untangle tcc_relocate() -> tcc_relocate_ex() -> set_pages_executable(), but it seems to me that since tcc sizes and then populates the 'mem' from above, it could certainly add metadata to allow a helper could undo the page protection and any other platform-specific actions that are required before free()-ing the memory. Perhaps something like tcc_unprotect(mem), which would only be allowed when one is done with the memory passed to tcc_relocate(). The alternative is having to know about messy system-dependent details, which seems very much against the spirit of the (lovely) libtcc API. Comments? ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
