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
