Re: [Tinycc-devel] Hello and a few questions about using libtcc

[Kyryl Melekhin]

On Sun, Dec 20, 2020 at 2:03 PM Joshua Scholar <joshuascholar@gmail.com> wrote:
> 1) If I've generated some code into a memory buffer and I've retrieved an 
> entry point with tcc_get_symbol, is it safe to call tcc_delete_state before I 
> call the entry point?  Looking at the source code, it looks like 
> tcc_delete_state deletes some things that you don't need at run-time.
>
> 2) If you use TCC_RELOCATE_AUTO, does tcc ever delete that memory for you?  
> Does  tcc_delete_state delete the generated code?  I do realize that if I 
> supply a buffer myself, I have to make it executable myself, but then I can 
> also know that I can delete it.
>
> 3) Does the tcc compiler allocate space for a stack?  Or is it that when you 
> call into code it generated, it uses your current stack? Or is there a 
> difference between tcc_run and just calling a function you got back from 
> tcc_get_symbol, where tcc_run allocates its own stack?
>
> 3 a) I noticed that there's a bounds checking version of alloca, but I 
> couldn't understand it.  Does this imply an answer to my previous question, 
> that TCC DOES allocate its own stack? Generally operating systems expand user 
> stacks as needed, up to a point, so bounds checking a stack doesn't make a 
> lot of sense.
>
> 4) Is it possible to reuse a TCCState? What would it do?  Would it trash the 
> code already generated?  Would it remember symbols from previous compiles?
>
> 5) Is the compiler thread safe?  While it would be surprising, I might as 
> well ask if you can compile multiple sources at once.
>
> Now questions about generated code.  The jit I'm hoping to make is for a 
> language that's embarrassingly parallel, so I need to know how the generated 
> code works with threads and stacks and contexts.
>
> 1) The simplest thing, what's the calling convention of generated functions?  
> On 64 bit windows?  On 64 bit Linux?
>
> 2)  Is the TCC runtime multithread safe?
> a) And what are the details?  Can I run generated code in multiple threads at 
> once?  Does it use locks for anything?
> Is it at least as thread safe as C usually is, ie, you can do anything that 
> doesn't involve a shared buffer like an implicit error string. Would it be 
> fine as long as I put a critical section around some non-thread safe part?
>
> 3) Does the run time library use thread local storage?
>
> 4) If I did something weird like have a call out from generated code to my 
> code, and my code returned on the same stack but in the context of a 
> different thread than it entered from, would that break anything?
>
> 5) Some systems are broken by fibers, ie, if I switched between generated 
> code, each using a different stack, but in the same thread, would that break 
> anything?
>
> 6) Are there any pointers on how to use the built in assembler?
>

I'll do my best to answer these, make sure to reply if any corrections
are necessary.

1. tcc_delete_state is not a thing, you mean tcc_delete? No,
tcc_delete will free everything, if you call it before running
generated code it will crash. But you could free some stuff from
TCCState, just make sure to not call tcc_run_free() if you don't plan
to ever use the state for compiling.

2. TCC_RELOCATE_AUTO means that the TCCState manages the code's
memory, and no, you still have to free it manually by calling
tcc_delete() or tcc_run_free(). The memory pointer is s->runtime_mem

3. No. The program does not create additional stacks. tcc_run creates
a section in memory and calls __init_array_start, just like any normal
C program would when you run it with libc. But because it goes through
the new section init it will allocate the amount of static memory it
needs. So you can expect the static memory to be set 0.

3a Bounds checking code is for debug only, there are special trap
instructions inserted by compiler if you enable it, but it will not
mitigate any program errors, it can detect stackoverflow and report
it, but that's the extent. It also checks the memory sections for
buffer overflows.

4. Yes you can reuse it, but it's not going to be efficient because it
will have to recompile the previous stuff also.

5. I'd say no, a compiler is not thread safe unless you run a TCCState
per thread.

-----

1.  Read code in gfunc_prolog gfunc_epilog. But I am confused by this
because x64 only has one calling convention, so I don't understand why
it matters except for i386 really. Windows is like the only exception
that does not follow the abi, but the difference is only register
order. Convention is fastcall

2. There is one semaphore in the code, but all I can tell you is that
it's there for some specific reason which I can't recall

3. No

4. I don't see any problems doing that. Stack memory is generally
thread safe and reentrant.

5. No idea what that means, probably no though

6. Use keywords like asm() or __asm() or __asm__() and only GAS
assembly syntax is supported.